Who should own the move toward Zero Trust in an identity programme?

Why This Matters for Security Teams

zero trust succeeds or fails on ownership, not slogans. In an identity programme, the shift changes how authentication is proven, how authorisation is evaluated, and how sessions are continuously rechecked. That means identity, security architecture, and PAM cannot treat it as a downstream network control. The operating model has to span policy, controls, review cadence, and exception handling.

NIST’s NIST SP 800-207 Zero Trust Architecture frames Zero Trust as a strategy built around explicit verification and least privilege, which makes it an identity governance problem as much as a technical one. NHI Management Group’s Ultimate Guide to NHIs shows why that matters in practice: 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. In mixed estates, the biggest mistake is assuming people ownership alone can drive change when service accounts, API keys, and machine identities often carry the actual blast radius.

In practice, many security teams encounter the ownership gap only after privileged access reviews, service outages, or secrets exposure have already surfaced the real control failures.

How It Works in Practice

Ownership usually works best as a shared operating model with a single accountable lead. Identity owns authentication standards, lifecycle governance, and policy consistency. Security architecture defines target-state controls, trust boundaries, and enforcement points. PAM owns privileged session controls, credential issuance, and elevation workflows. This is the practical pattern behind Zero Trust, because access must be evaluated at the moment of use, not assumed from a prior login.

For non-human identities, the model needs to go further. Service accounts, workload identities, API keys, and certificates should be governed as first-class identities, not hidden implementation details. NHI Management Group’s Top 10 NHI Issues and Ultimate Guide to NHIs — Standards both reinforce the same operational reality: Zero Trust depends on visibility, rotation, offboarding, and policy enforcement across the full identity estate. Where possible, teams should align workload identity with cryptographic proof of what the workload is, then apply just-in-time access and short-lived secrets instead of long-lived standing credentials.

• Identity defines the access policy model and review cadence.
• PAM enforces elevation, session monitoring, and credential containment.
• Architecture maps trust zones, enforcement points, and control exceptions.
• Security operations monitors drift, misuse, and anomalous revalidation events.

Current guidance suggests the model should be policy-driven and continuously revalidated, but there is no universal standard for how ownership should be split across all organisational structures. These controls tend to break down in legacy environments with shared admin accounts and hard-coded secrets because enforcement cannot be tied cleanly to a single identity or session.

Common Variations and Edge Cases

Tighter ownership usually improves control consistency, but it also increases coordination overhead, requiring organisations to balance stronger governance against slower change management. That tradeoff becomes visible in federated enterprises, regulated environments, and hybrid cloud estates where different teams control different layers of the stack.

Some organisations place the programme under IAM because the core work is identity lifecycle and policy. Others place it under security architecture because Zero Trust is a design pattern that spans networks, apps, and endpoints. Best practice is evolving toward a joint model with explicit RACI, because ambiguous ownership creates exceptions that become permanent. For implementation detail, the Guide to SPIFFE and SPIRE is useful when teams need to translate Zero Trust into workload identity and short-lived credentials.

The edge cases are usually old ones: shared admin credentials, vendor-managed access, emergency break-glass paths, and service accounts embedded in CI/CD. Those situations need compensating controls, not wishful ownership. In practice, the programme slows down when legacy systems cannot support per-session validation or short-lived credential issuance because the control model cannot be enforced consistently.

Related resources from NHI Mgmt Group

• Who should own Zero Trust policy decisions in a mature identity programme?
• Who should own SaaS reporting outputs in an identity programme?
• Who should own vendor risk management in an identity programme?
• Who should own shadow IT findings in a mature identity programme?