What do identity teams get wrong when they treat infrastructure ownership as control?

Why This Matters for Security Teams

When identity teams equate infrastructure ownership with control, they often inherit the operational burden without gaining better governance. Platform possession can improve responsiveness, but it does not automatically improve authorisation quality, credential hygiene, or offboarding discipline. That distinction matters because NHI risk is usually created by policy gaps, stale secrets, and unclear accountability rather than by who runs the servers. NHIMG’s Ultimate Guide to NHIs shows how frequently organisations struggle with lifecycle control, while NIST Cybersecurity Framework 2.0 keeps the emphasis on outcomes, not asset ownership.

The practical error is assuming that the team closest to the infrastructure can therefore govern it better. In reality, ownership can turn into self-preservation: time goes to maintaining pipelines, preserving access paths, and defending platform boundaries instead of enforcing least privilege. That is especially visible in environments with service accounts, API keys, and agentic workloads, where the risk surface is created by secrets and permissions, not by rack location or cloud tenancy. The strongest governance question is not who owns the stack, but who can prove access is necessary, time-bound, and revoked when it is no longer needed. In practice, many security teams discover this only after stale access or overprivileged non-human identities have already been exploited, rather than through intentional control design.

How It Works in Practice

Effective control starts by separating platform operation from policy authority. Infrastructure teams may manage deployment, logging, and uptime, but identity teams should define the rules for entitlement, secret lifetime, and revocation. For non-human identities, that means treating service accounts, workload identities, API keys, and agent credentials as governed assets with explicit owners, expiry, and audit evidence. The current guidance suggests using Ultimate Guide to NHIs - Standards as a reference point for lifecycle controls, then mapping those controls to business process rather than to infrastructure topology.

• Use central policy to decide what the identity may do, not just where the workload runs.
• Issue credentials through JIT or short-lived mechanisms when feasible, and revoke them automatically at task completion.
• Prefer workload identity over shared static secrets so access can be tied to the workload, not the machine image.
• Require offboarding procedures for non-human identities just as rigorously as for employees.
• Measure evidence quality, such as who approved access, when it expires, and whether revocation was actually completed.

This is where identity teams add value: they create a decision layer above infrastructure, so operational convenience does not become standing privilege. The NIST view of governance reinforces that point, because outcome-based controls are easier to verify than asset ownership claims. NHIMG’s research on non-human identities also shows why this matters: excessive privileges and poor rotation remain common, which means the control problem is usually policy enforcement, not platform possession. When this model breaks down, it is usually in highly fragmented environments where cloud, on-prem, and SaaS teams each maintain separate secret stores and no single authority can enforce revocation consistently.

Common Variations and Edge Cases

Tighter control often increases coordination cost, requiring organisations to balance faster platform changes against stronger approval and revocation discipline. That tradeoff becomes sharper in regulated environments, during migrations, and in teams that rely on shared clusters or inherited admin roles. There is no universal standard for this yet, but current guidance suggests that ownership should be treated as an operational responsibility, while control remains a policy function with independent checks.

One common edge case is the “builder owns control” model, where the team that created the infrastructure also approves access. That can work for small systems, but it tends to fail as soon as the estate grows, because the same team becomes judge, operator, and evidence collector. Another case is incident response, where temporary delegated authority is necessary. Even there, the delegation should be time-bound and auditable, not open-ended. The most reliable pattern is a clear separation between platform administration, identity policy, and exception handling, with each role documented and reviewable. For deeper context on how overprivilege and weak rotation drive breaches, NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues remain the most useful references. Best practice is evolving toward policy-first control, especially where infrastructure ownership is distributed across multiple teams and no single group has complete operational visibility.

Related resources from NHI Mgmt Group

• What do identity teams get wrong when they treat SOC and SOX as the same control problem?
• What do teams get wrong when they treat identity verification as a one-time compliance task?
• What do teams get wrong when they treat self-service request portals as identity governance?
• What do teams get wrong when they treat AI assistants as infrastructure?