Who should own network-layer identity controls in an enterprise?

Why This Matters for Security Teams

Network-layer identity controls sit at the junction of authentication, policy enforcement, and traffic steering, which is why ownership disputes create real operational risk. If IAM only governs login, network teams only manage segmentation, and PAM only handles elevation, the enterprise can end up with three partially enforced policies instead of one control plane. NIST’s NIST SP 800-207 Zero Trust Architecture makes this point clearly: access decisions must follow the request, not just the user or device.

For NHI-heavy environments, this becomes more urgent because identities are not just human users. Service accounts, API keys, workload identities, and agent credentials often traverse network boundaries that traditional IAM workflows do not fully see. NHI Management Group has shown in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which means ownership gaps are usually also visibility gaps.

In practice, many security teams discover misrouted identity controls only after lateral movement or unauthorized service access has already occurred, rather than through intentional governance reviews.

How It Works in Practice

Effective ownership is usually shared, but not indistinctly shared. IAM should own identity proofing, lifecycle, credential issuance, and policy definitions. Network security should own enforcement points such as segmentation, allowlists, proxy controls, and service-to-service routing. PAM should own privilege elevation, just-in-time access, and approval workflows where privileged network actions are involved. The operating model fails when any one team assumes the others will “pick up the rest.”

In mature environments, the control objective is to bind the identity of the requester to the network action at the moment the request is made. That means a workload or operator is authenticated, authorized, and then allowed to traverse only the specific network path needed for the task. This is aligned with the NHIMG standards guidance and with the Zero Trust model in NIST SP 800-207.

• IAM defines who or what can request access, including service accounts and workloads.
• PAM governs when elevated network actions require approval or short-lived privilege.
• Network security enforces microsegmentation, route constraints, and policy-based access decisions.
• All three teams should share logging, review, and exception handling so drift is visible early.

The strongest programs also tie network-layer identity to a lifecycle process: issuance, review, rotation, revocation, and offboarding. NHIMG’s 52 NHI Breaches Analysis shows how quickly weak controls become incident material when identities outlive their intended scope. These controls tend to break down in hybrid environments where legacy network appliances cannot evaluate identity context at request time because the enforcement layer is too old to consume modern policy signals.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance stronger governance against slower change cycles. That tradeoff is real, especially when network teams operate separate tooling from IAM or when PAM approvals add latency to operational access.

Current guidance suggests there is no universal standard for a single “best” owner, but there is a clear pattern: central policy ownership with distributed operational responsibility works better than siloed ownership. In cloud-native environments, IAM may lead because workload identity and token issuance are the dominant control points. In data center or OT-adjacent environments, network security may lead because enforcement happens in appliances and segmentation layers. For agentic systems, the ownership question shifts again because autonomous software can chain tools and request access dynamically, so runtime authorization becomes more important than static role assignment.

That is why teams should define one accountable control owner, then assign named co-owners for implementation and exceptions. NHIMG’s Top 10 NHI Issues reinforces that excessive privileges, weak rotation, and poor visibility often appear together. The practical rule is simple: one team can coordinate the control, but no single team should be allowed to define, approve, and enforce it alone.

Related resources from NHI Mgmt Group

• Who should own identity graph governance in an enterprise?
• Should organisations build their own identity layer or buy one for .NET enterprise apps?
• Who should own workforce identity verification controls in an enterprise?
• How should teams implement continuous compliance monitoring for identity controls?