Identity lifecycle management needs continuous governance across all identities

At a glance

What this is: This is an analysis of how identity lifecycle management has to move from periodic administration to continuous governance across human and non-human identities.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all fail in the same place when access outlives intent, especially as service accounts and AI agents enter the lifecycle model.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Opal Security's analysis of identity lifecycle management across human and machine identities

Context

Identity lifecycle management is the discipline of making sure access changes when the subject changes. In practice, that means provisioning, updating, reviewing, and revoking access when a person moves roles, a service account changes purpose, or an AI agent is introduced into the environment.

The governance gap is that many programmes still treat lifecycle as a periodic administrative task instead of a continuous control plane. Once access is defined by static roles, brittle groups, or delayed reviews, privilege accumulates faster than teams can observe or remove it.

Opal Security frames this as a need to govern access continuously across identity types, which is directionally correct even when the implementation details differ. The underlying issue is not just automation, but whether the programme can keep entitlement state aligned with operational reality.

Key questions

Q: How should security teams govern identity lifecycle across humans and non-human identities?

A: Security teams should govern lifecycle with one model and different triggers. Humans need joiner, mover, leaver controls tied to HR and access approvals. Service accounts and AI agents need the same lifecycle discipline, but with creation, repurposing, and retirement tied to system ownership, application decommissioning, and verified downstream revocation.

Q: Why do orphaned accounts remain a major IAM risk?

A: Orphaned accounts remain risky because access often outlives the business reason for it. When offboarding is incomplete, an account can persist in SaaS tools, infrastructure, or delegated systems long after the subject has changed. That creates hidden standing access that attackers can exploit and auditors may not immediately see.

Q: What do organisations get wrong about access reviews?

A: They often treat access reviews as a substitute for lifecycle control. Reviews are only useful if the inventory is current, the grant source is visible, and stale accounts have already been removed or flagged. Otherwise, reviewers certify outdated access and miss the real problem, which is entitlement drift between review cycles.

Q: Who is accountable when a service account or AI agent keeps access after offboarding?

A: Accountability should sit with the system owner and the identity governance owner, not just the team that requested the access. If a service account or AI agent keeps access after offboarding, that usually means the lifecycle trigger, downstream revocation, or ownership mapping was incomplete. The control failure is organisational, not just technical.

Technical breakdown

Dynamic entitlement governance and attribute-enriched policy

Dynamic entitlement governance replaces fixed, manually maintained access assignments with policy that recalculates entitlements as context changes. Attribute-enriched policy means access decisions can consider role, system state, request source, or workflow trigger instead of relying only on group membership. That matters because static RBAC breaks down when the same person, workload, or agent has changing responsibilities across systems. The technical risk is policy drift, where old grants remain active after the original reason for access has disappeared. Transparent grant provenance is critical because it lets teams see whether access came from a direct rule, a group, or an inherited policy chain.

Practical implication: map every standing entitlement to a source of authority so drift can be detected before access compounds.

JML workflows for humans, service accounts, and AI agents

Joiner, mover, leaver workflows are the same governance pattern applied to different actor types. For humans, JML aligns with hire, role change, and offboarding. For service accounts and AI agents, it becomes creation, repurposing, and retirement based on operational need. The technical challenge is that non-human identities are often created in one system, consumed in another, and never cleanly retired in either. If provisioning and deprovisioning are not tied to authoritative lifecycle events, accounts linger as orphaned access. That is why lifecycle governance must treat the identity subject, the approval source, and the downstream account as linked but distinct objects.

Practical implication: bind lifecycle events to account state changes in downstream systems, not just to HR or ticketing records.

Guardrails against bulk entitlement drift

Guardrails are the control layer that prevents a policy update from causing a large and unintended access change. In lifecycle systems, that usually means pausing unusually broad entitlement updates, checking for overlapping rules, and reviewing anomalies before they propagate. This is especially important when identity data sources are noisy, because a single bad attribute can trigger many downstream changes. Continuous risk analysis helps here by surfacing misaligned rules and inactive accounts before they become exposed. The architecture works only if exceptions are visible, reviewable, and reversible, otherwise automation simply accelerates misconfiguration.

Practical implication: place change thresholds and review gates around high-impact access updates, especially where one rule fans out to many accounts.

NHI Mgmt Group analysis

Identity lifecycle governance fails when access is treated as a one-time event. Traditional IAM and IGA models were built around provisioning and periodic review, not continuous entitlement state. Once a person changes role, a service account drifts, or an AI agent inherits new permissions, the original approval no longer describes actual access. Practitioners should treat lifecycle as a live control plane, not an administrative afterthought.

Lifecycle governance must be modelled by actor type, not by workflow label. Joiner, mover, and leaver processes look similar on paper, but the failure modes differ across humans, NHI, and autonomous systems. Human offboarding, service-account retirement, and AI-agent deactivation each need different sources of truth and different revocation triggers. Practitioners should stop assuming one lifecycle template can govern all identity subjects equally.

Transparent grant provenance is the named concept that makes lifecycle governance operational. If teams cannot explain why an entitlement exists, they cannot safely update or revoke it when context changes. This is the difference between access that is manageable and access that is merely present. Practitioners should require every grant to remain explainable across its full inheritance chain.

Access review programmes do not fix lifecycle drift if the underlying account state is already stale. Recertification is useful only when the inventory reflects current reality. Orphaned accounts, overlapping policies, and delayed revocation mean reviewers are certifying yesterday's access, not today's. Practitioners should treat recertification as an assurance layer, not as a substitute for continuous lifecycle control.

Lifecycle automation is now a control requirement for contractors, service accounts, and AI agents, not just employees. The market is moving toward unified governance because identity sprawl is no longer limited to people. Programmes that only modernise human JML will leave the highest-risk non-human identities unmanaged. Practitioners should extend lifecycle design across all identity classes before sprawl becomes irreversible.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The lifecycle problem is broader than secrets alone. Read NHI Lifecycle Management Guide for the control patterns that keep provisioning, rotation, and offboarding aligned.

What this signals

Transparent grant provenance will matter more as identity programmes converge across humans, service accounts, and AI agents. If teams cannot explain why access exists, they will not be able to govern why it should persist, and review programmes will keep certifying historical state instead of live entitlement reality.

The operational signal is simple. If your environment still needs manual intervention to revoke access cleanly at offboarding, your lifecycle model is not yet continuous. That gap tends to show up first in orphaned accounts, overlapping rules, and delayed revocation rather than in a single obvious failure.

With an average of six distinct secrets manager instances fragmenting control in some organisations, lifecycle governance cannot rely on a single point-in-time inventory. The reader should expect more pressure to unify identity state across IGA, PAM, and secrets workflows, using the 52 NHI Breaches Analysis as a reference for how drift becomes exposure.

For practitioners

• Inventory every identity subject by lifecycle owner Build a register that separates humans, service accounts, contractors, and AI agents, then assign an accountable owner to each subject and its downstream accounts. Use the inventory to expose identities that have no clear offboarding path or no current business purpose.
• Tie entitlement changes to authoritative events Trigger provisioning, updates, and revocation from authoritative lifecycle events such as HR status changes, approved requests, application decommissioning, or agent retirement. Avoid relying on periodic clean-up as the primary control for access removal.
• Add review thresholds for high-impact access changes Pause or require approval for broad entitlement changes, especially where a single policy update can affect many users or many connected systems. This is the practical way to catch accidental privilege expansion before it spreads.
• Trace inherited access paths before recertification Make reviewers see how access was granted, whether directly, through a group, or through a codified policy chain. Without access path visibility, recertification confirms the existence of access without validating its current justification.

Key takeaways

• Identity lifecycle management fails when access is allowed to outlive the business reason for it.
• The biggest governance issue is not provisioning speed alone, but whether entitlement state stays aligned with real-world role and ownership changes.
• Continuous lifecycle control across humans, service accounts, and AI agents is now a baseline requirement for least privilege.

Key terms

• Identity Lifecycle Management: Identity lifecycle management is the governance of access from creation to retirement. It covers provisioning, updates, reviews, and revocation so that access stays aligned with the current business reason, regardless of whether the identity is human, a service account, or an AI agent.
• Transparent Grant Provenance: Transparent grant provenance is the ability to explain why an entitlement exists and where it came from. It makes direct grants, inherited permissions, and policy-based access visible enough for teams to review, challenge, and revoke them when the original justification no longer applies.
• Orphaned Account: An orphaned account is an identity record that remains active after the owner, purpose, or upstream authority has changed. It is dangerous because the account can retain access even though no one is actively managing or validating that access anymore.
• Access Drift: Access drift is the gradual mismatch between intended permissions and actual permissions over time. It often appears when role changes, policy changes, or system changes are not reflected quickly across downstream applications, leaving excess access in place.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Opal Security: How Opal Streamlines Identity Lifecycle Management. Read the original.