Who should own the risk when identity and access management is implemented without standard protocols?

Why This Matters for Security Teams

When identity and access management is built without standard protocols, ownership becomes blurred fast. Security teams often inherit the risk because they are asked to approve exceptions, while platform teams absorb the operational burden of fragile integrations and custom token handling. That split creates a gap where nobody is clearly responsible for governance, lifecycle control, or incident response.

Standards matter because they reduce the number of one-off decisions that have to be defended later. The OWASP Non-Human Identity Top 10 and NIST guidance both point to the same practical issue: bespoke IAM logic increases the chance of inconsistent privilege assignment, weak revocation, and hidden dependencies. In NHIMG’s Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which shows how easily unmanaged access expands when no common operating model exists.

In practice, many security teams encounter the failure only after an API incident, a leaked secret, or a service outage has already exposed how much custom IAM logic was never properly owned.

How It Works in Practice

The practical answer is shared accountability with explicit control boundaries. Security should own the policy, risk acceptance, and audit criteria; platform or engineering teams should own implementation, integration, and runtime enforcement. That model is easier to sustain when IAM uses standard protocols such as OIDC, SAML where needed, and workload identity patterns that avoid long-lived shared secrets. The NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support this split by tying identity governance to repeatable control outcomes rather than ad hoc service decisions.

For NHI-heavy environments, standard protocols also make lifecycle control much more realistic. Teams can centralise issuance, enforce short TTLs, and revoke access at source instead of chasing embedded credentials across code, CI/CD pipelines, and configuration stores. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs highlight why this matters: without lifecycle discipline, access sprawl and stale secrets become structural risks, not isolated mistakes.

• Define one accountable owner for policy, one for implementation, and one for exception approval.
• Use standard token formats and workload identity where possible, not service-specific shortcuts.
• Require issuance, rotation, and revocation workflows to be automated and auditable.
• Map every non-standard integration to a compensating control and an explicit expiry date.

These controls tend to break down when legacy services depend on embedded static secrets or when multiple teams independently build identity logic for the same workload.

Common Variations and Edge Cases

Tighter standardisation often increases delivery overhead, so organisations have to balance faster integration against the cost of refactoring legacy services. That tradeoff is real, especially in environments with older middleware, partner APIs, or mixed cloud and on-premises estates.

Current guidance suggests that not every system can move to the same protocol immediately. Some legacy applications may need compensating controls, such as network segmentation, secret vaulting, and aggressive rotation, while the longer-term plan is to migrate them to a standard identity model. The important point is that exceptions should be temporary, documented, and owned. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because audit teams usually need evidence that ownership, review cadence, and revocation paths are defined even when the protocol is not ideal.

In governance terms, the risk should sit with the business unit that accepts the exception, while security retains oversight of the control framework. That prevents “shadow IAM” from emerging in engineering teams and keeps the exception tied to a measurable remediation plan. Where the environment includes high-velocity APIs, customer-facing services, or third-party integrations, bespoke IAM tends to accumulate technical debt faster than teams can document it.

Related resources from NHI Mgmt Group

• How should financial institutions use converged identity and access management to support digital transformation without weakening security?
• How should security teams register identity risk assessments in a community model without creating access friction?
• Why do identity security programmes need more than standard access management in SaaS-heavy environments?
• How should security teams automate identity lifecycle management without creating new access risk?