Who should be accountable for enforcing least privilege across the identity lifecycle?

Why This Matters for Security Teams

least privilege is not a one-time access review problem. It is an identity lifecycle control that has to hold during provisioning, privilege elevation, rotation, and revocation. When accountability is vague, excessive access accumulates in service accounts, API keys, vaults, and CI/CD pipelines. That is why NHIMG’s Ultimate Guide to NHIs treats lifecycle governance as a core security function, not a back-office task.

This is also where many programmes fail in practice. Security teams often assume owners will clean up access after onboarding, but the control gap usually appears later, when offboarding, emergency changes, or inherited permissions leave standing access behind. NIST reinforces this with Zero Trust Architecture, which requires continuous evaluation instead of implicit trust in inherited privileges. NHIMG research shows the operational impact: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames, which means least privilege is failing at the exact point where identity risk compounds fastest. In practice, many security teams encounter excessive access only after a token leak, service outage, or breach investigation, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability should sit with identity and security leadership, but enforcement needs a shared operating model. Identity governance teams usually define the policy, security architects define the control intent, platform and application owners supply context, and system owners approve the business need for access. The key is that every stage of the lifecycle has a named control owner and an auditable decision trail.

In practical terms, least privilege should be enforced at four points:

• Discovery: identify every human and non-human identity, including dormant, inherited, and embedded credentials.
• Provisioning: grant the minimum role, scope, and duration required for the task.
• Review and change: revalidate access when the application, workload, or business purpose changes.
• Revocation: remove access immediately when the identity is no longer needed or no longer trusted.

For NHIs, this is where lifecycle discipline matters most. NHIMG’s NHI Lifecycle Management Guide and Top 10 NHI Issues both point to the same operational reality: excessive privilege, poor rotation, and weak offboarding are usually symptoms of unclear ownership. The right answer is not just “the IAM team” or “the app owner.” It is an accountable control chain, backed by policy, approvals, and monitoring.

Where teams need a policy baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls supports access control, account management, and auditability expectations. These controls tend to break down when identity ownership is split across platform, DevOps, and security teams because no one is explicitly measured on revocation timeliness.

Common Variations and Edge Cases

Tighter least-privilege enforcement often increases administrative overhead, requiring organisations to balance rapid delivery against stronger control assurance. That tradeoff becomes visible in environments with many short-lived workloads, delegated administration, or third-party integrations, where access changes are frequent and context is incomplete.

Best practice is evolving for these cases. Some organisations place primary accountability in identity security, with application owners accountable for business justification and platform teams accountable for technical enforcement. Others use a federated model with central policy and distributed execution. There is no universal standard for this yet, but the accountability owner should always be able to prove who approved access, who enforced it, and who validated removal.

The hardest edge case is non-human identity sprawl. When credentials are embedded in code, shared across tools, or reused by multiple services, enforcement can be technically possible but operationally weak. NHIMG’s Guide to the Secret Sprawl Challenge and lifecycle processes for managing NHIs are relevant here because least privilege fails when secrets are duplicated faster than governance can track them. In those environments, accountability must extend beyond review forms to automated controls, continuous detection, and immediate revocation workflows.

Related resources from NHI Mgmt Group

• Who is accountable for enforcing least privilege when secrets are injected at execution time?
• How should identity teams prioritise least privilege across SaaS applications and data access in a mature programme?
• Who should be accountable when identity fraud moves across compliance, fraud, and verification teams?
• Who should be accountable for hybrid identity resilience across Active Directory, Entra ID, Okta, and Ping?