Who should own identity lifecycle automation decisions across IT, security, and HR?

Why This Matters for Security Teams

Identity lifecycle automation only works when decision rights are explicit. If IT runs the workflow without shared ownership, onboarding and offboarding logic can silently diverge from HR status, security policy, and application context. That creates the same failure pattern seen across NHI programs: fast automation with inconsistent inputs. NHI Management Group’s The State of Non-Human Identity Security shows how easily visibility and control gaps persist when ownership is fragmented.

This is not just a process issue. Lifecycle decisions determine who can create identities, approve access, revoke credentials, and validate exceptions. In practice, those choices shape whether automation actually reduces risk or simply scales bad approvals faster. The OWASP Non-Human Identity Top 10 treats lifecycle failures as a core security weakness because stale access, unclear accountability, and poor rotation are repeatedly exploited. One relevant NHIMG finding is that 91% of former employee tokens remain active after offboarding in the 2025 State of NHIs and Secrets in Cybersecurity research from Astrix Security & CSA. In practice, many security teams discover ownership gaps only after offboarding or access exceptions have already been missed, rather than through intentional governance design.

How It Works in Practice

The most durable model is shared governance with a single operating owner for the workflow and clear decision owners for the inputs. IT usually owns the automation platform, ticketing, integrations, and technical enforcement. HR owns employee status changes, start and end dates, and employment events. Security owns policy, control requirements, exception handling, and revocation standards. GRC helps define evidence, approvals, and auditability. Application owners validate which identities, groups, service accounts, or secrets are actually needed.

For NHI lifecycle management, that means the workflow should not ask, “Who clicks approve?” first. It should ask, “Which events trigger identity creation, which attributes determine access, and who can override revocation?” The NHI Lifecycle Management Guide is useful for structuring those lifecycle stages, while the Lifecycle Processes for Managing NHIs section shows why creation, rotation, renewal, suspension, and deprovisioning cannot be treated as one generic approval flow.

• Use HR as the authoritative source for human status changes, but not as the sole approver of security access.
• Use security policy to define mandatory revocation windows, JIT rules, and exception thresholds.
• Use IT to automate API calls, identity updates, and system synchronization.
• Require application owners to confirm access necessity for sensitive or high-risk systems.

The practical standard is to separate data ownership from control ownership: one team owns the source data, another owns the policy decision, and IT executes the automation. Guidance is still evolving for fully autonomous approval paths, but current practice strongly favors policy-as-code controls and traceable approvals over informal handoffs. These controls tend to break down when multiple HR systems, decentralized application owners, or unmanaged service accounts create conflicting lifecycle events because no single system has complete authority over the identity state.

Common Variations and Edge Cases

Tighter ownership control often increases coordination overhead, so organisations must balance speed against auditability and revocation accuracy. That tradeoff becomes sharper in environments with contractors, third parties, and machine identities, where lifecycle events do not map cleanly to a single HR record. The Guide to the Secret Sprawl Challenge is a reminder that lifecycle ownership extends beyond joiner-mover-leaver workflows into secrets and credentials that outlive the person or pipeline that created them.

There is no universal standard for this yet, but current guidance suggests a federated operating model: central policy, distributed data stewardship, and system-level enforcement. That matters most where application teams can create local accounts, where mergers leave multiple HR sources, or where a platform team manages service identities that security does not fully see. In those cases, ownership should be documented in a RACI or similar decision-rights model and tied to revocation SLAs, not left as an informal convention. For reference, OWASP NHI guidance and NHIMG research both emphasise that lifecycle breakdowns often begin with unclear accountability rather than tooling failure. Organisations that skip that governance step usually find the problem during an access review or incident, when stale identity records are already in production.

Related resources from NHI Mgmt Group

• Who should own identity security when access spans users and machine identities?
• Who should own phishing-resistant MFA governance across the identity programme?
• How should security teams make NHI best practices usable across the business?
• Who should own non-human identity lifecycle decisions?