Who should own access control and configuration failures in modern application estates?

Why This Matters for Security Teams

Access control and configuration failures are rarely caused by a single bad setting. They usually emerge where application logic, cloud baseline hardening, and identity governance overlap, and that is exactly where ownership gets blurred. Security teams can write policy, but only the team that can change the control in production can verify whether it actually works under live traffic.

This is why modern estates need clear control ownership, not just shared accountability language. A mis-scoped authorization rule in application code is different from an exposed storage policy or a stale privileged role, yet all three can produce the same outcome: unauthorized access. Guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward control accountability, but the practical challenge is operational ownership, not policy language.

NHIMG’s research on real-world incidents shows how quickly identity and configuration weaknesses become breach paths, including the Microsoft SAS Key Breach and the broader patterns captured in the 52 NHI Breaches Analysis. In practice, many security teams encounter control drift only after an incident report reveals that no production team had a runtime test for the control’s actual behavior.

How It Works in Practice

The cleanest model is to assign ownership by control layer. Application engineering owns authorization logic, resource scoping, and any policy decisions embedded in the service. Cloud platform or infrastructure teams own baseline configuration, such as network exposure, storage policy, encryption defaults, and secure service templates. Identity teams own privileged access, trust relationships, and the lifecycle of non-human identities and secrets. That division only works when each team is accountable for measurable runtime outcomes, not just ticket closure.

Practitioners should define who can change the control, who can approve exceptions, and who must verify the control in production. That usually means a shared control register with named owners, evidence requirements, and a test that proves the control blocks the unsafe action. For example:

• Application teams test whether broken authorization can still be bypassed.
• Platform teams test whether insecure defaults can be introduced through deployment paths.
• Identity teams test whether privileged access is time-bound, scoped, and revoked correctly.

This is where current guidance aligns with CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management: assign accountability, verify implementation, and review it continuously. NHIMG’s Ultimate Guide to NHIs reinforces that non-human identities are operational controls, not abstract assets, so ownership must sit with the team that can rotate, restrict, and revoke them in real time. The same is true when secrets or trust policy are being abused, as shown in NHIMG’s DeepSeek breach. These controls tend to break down when ownership is assigned by organizational chart rather than by the team that controls the runtime path.

Common Variations and Edge Cases

Tighter control ownership often increases coordination overhead, requiring organisations to balance clear accountability against delivery speed. That tradeoff becomes visible in shared platform services, platform engineering models, and multi-team product lines where one control spans several execution layers.

There is no universal standard for this yet, but best practice is evolving toward a single accountable owner per control with supporting contributors. In a microservices environment, one service may own business authorization while another owns token validation, so the runtime test has to reflect the full chain. In a managed cloud service, the cloud provider may set some defaults, but the application team still owns secure configuration choices and exception handling. In M&A environments, inherited identity estates often create split ownership, and that is where stale permissions, duplicate secrets, and shadow admin paths persist longest.

For this reason, many teams use a control-to-owner map that is reviewed alongside incident and change management. If no team can prove they can test the control in production, ownership is still unresolved even if a RACI matrix says otherwise. That distinction matters because control failures usually surface where policy, deployment, and identity intersect, not where the org chart says they should.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• Why do non-human identities create audit risk in modern environments?
• When do NHI access reviews create more value than a one-time cleanup?