Look for repeated exceptions in claims mapping, manual SSO setup, role logic inside applications, and policy decisions scattered across services. Those patterns show that identity governance is no longer centralised. Once access rules live in too many places, audits become harder and recertification loses reliability.
Why This Matters for Security Teams
Identity controls drift into custom code when teams stop using a central policy and lifecycle model and start embedding access logic inside applications, scripts, and ad hoc approvals. That drift is hard to see because it often appears as temporary exception handling or “just one workaround” for a service account, API key, or OAuth app. Over time, those exceptions become the real control plane, which weakens auditability and makes recertification unreliable. The pattern is visible in the Ultimate Guide to NHIs, where NHIs outnumber human identities by 25x to 50x in modern enterprises.
This matters because custom identity logic usually spreads faster than governance can keep up. Security teams often discover it only after a failed access review, a secrets leak, or a breach tied to an over-privileged service identity. The NIST Cybersecurity Framework 2.0 still assumes clear ownership, consistent enforcement, and repeatable control operation. Once those assumptions break, control evidence becomes fragmented and exceptions become the norm. In practice, many security teams encounter this only after access reviews stop matching production reality.
How It Works in Practice
The strongest signal is not “there is code somewhere,” but that identity decisions are being made in code instead of being enforced by a shared control layer. Common indicators include claims mapping maintained by engineers, role assignment rules hidden in app logic, manual SSO onboarding steps, and service-specific allowlists that bypass standard approval paths. That is where identity governance becomes custom work rather than a managed function.
Security teams should look for repeated patterns across systems, not isolated exceptions. A useful review path is:
- Check whether access decisions rely on local if-then logic instead of policy-as-code or a centralized entitlement source.
- Inspect whether service accounts, API keys, and OAuth tokens are provisioned by ticket, script, or application workflow without standard lifecycle controls.
- Compare audit logs against the intended approval model to see whether actual access paths match documented policy.
- Review whether rotation, revocation, and recertification happen in one system of record or are patched into each application separately.
The governance signal improves when teams map findings to a broader control model such as Top 10 NHI Issues and align operationally with NIST CSF functions for access control, monitoring, and response. Current guidance suggests that if identity policy cannot be enforced without application code changes, the organisation has already crossed from governance into bespoke engineering. These controls tend to break down when every product team owns its own authorization layer because no single team can prove complete coverage.
Common Variations and Edge Cases
Tighter identity governance often increases delivery friction, requiring organisations to balance consistent enforcement against application autonomy and release speed. That tradeoff is real, especially in engineering-heavy environments where teams have historically owned their own authentication and authorization logic.
There is no universal standard for when a workaround becomes unacceptable, but current guidance suggests treating any recurring exception as a drift signal. A single scripted onboarding flow may be acceptable if it is still governed by central policy, logged, and revocable. The risk rises when the script becomes the approval mechanism, the entitlement source, and the rollback path all at once.
Edge cases often appear in legacy systems, internal developer platforms, and SaaS integrations. In those environments, teams may need to accept short-term custom code while they migrate toward centralized control, but the migration should be explicit and time-bound. The Ultimate Guide to NHIs — Standards is useful here because it helps distinguish technical integration work from durable governance. Where multiple apps each implement their own authorization rules, security teams should assume control drift is already present unless central policy proves otherwise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Custom code often hides weak rotation and revocation for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Drift shows access enforcement is no longer centrally governed. |
| NIST AI RMF | Governance drift is a risk-management issue requiring clear accountability. |
Find recurring exceptions and replace ad hoc identity handling with centrally managed rotation and revocation.
