Because applications often make their own access decisions at runtime. Login flows, session handling, OAuth logic, and object-level authorisation can override central policy if they are poorly designed or unreviewed. The result is a hidden enforcement layer where access is granted or denied outside the IAM programme’s direct control.
Why This Matters for Security Teams
Applications become a risk surface when they re-implement authentication, authorisation, and session logic in ways that are only loosely aligned to central IAM policy. That matters because IAM tools are strongest at controlling identity lifecycle, federation, and coarse-grained access, while application code often decides what a user or token can do at the object, action, or request level. If those checks are weak, inconsistent, or undocumented, a clean identity record can still lead to excessive access.
This is not just a design issue. It creates audit gaps, incident response blind spots, and a false sense of control when access reviews focus on directory groups or SSO configuration alone. Security teams also miss the operational reality that application owners may change routes, API scopes, or business rules faster than IAM governance can track. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames identity-related risk as a broader governance and protection problem, not just an access provisioning issue.
In practice, many security teams encounter this only after a broken authorisation check, privilege abuse, or data exposure has already occurred, rather than through intentional application-level review.
How It Works in Practice
Applications create identity and access risk because they often contain multiple enforcement points that sit outside the IAM programme. A user may authenticate through SSO, but the application still decides whether that session can read a record, call an API, assume a role, or bypass a workflow. In modern architectures, that decision can be spread across front-end code, backend services, API gateways, OAuth scopes, claims mapping, and object-level controls.
That is why IAM visibility alone is incomplete. Central tools can confirm that a token was issued or a role was assigned, but they cannot always tell whether the application is enforcing least privilege correctly at runtime. Security teams should therefore assess both the identity path and the application path:
- Validate whether the application trusts identity claims without re-checking scope, tenant, role, or resource ownership.
- Review session lifetimes, token reuse, refresh logic, and logout handling for excessive persistence.
- Test object-level authorisation for IDOR-style failures where a valid user can reach another user’s data.
- Map custom business rules to approved control requirements, not just to login success.
- Inspect service-to-service and machine identity use cases, especially where apps rely on secrets or tokens outside standard IAM workflows.
For non-human identities, the same problem often appears with API keys, service accounts, and automation tokens that are embedded in code or orchestration logic. The OWASP Non-Human Identity Top 10 is relevant because it highlights how identity sprawl and weak secrets governance can bypass central oversight. NIST guidance on control design in NIST SP 800-53 Rev 5 Security and Privacy Controls supports the practical need for access enforcement, auditing, and configuration discipline across the application stack.
These controls tend to break down in fast-moving microservice environments because authorisation logic is duplicated across services and rarely tested as one coherent policy set.
Common Variations and Edge Cases
Tighter application enforcement often increases engineering and test overhead, requiring organisations to balance stronger access control against delivery speed and code complexity.
There is no universal standard for this yet, especially in environments that mix legacy monoliths, APIs, SaaS integrations, and AI-enabled workflows. Some applications rely mainly on central IAM for coarse access and then use local rules for sensitive actions; others embed full authorisation logic in code. The risk is highest when teams assume the SSO layer has solved the problem end to end.
Edge cases include multi-tenant systems, delegated admin models, shadow APIs, and applications that accept external tokens from partners or agents. In those environments, a legitimate identity can still be dangerous if the app fails to bind the session to the right tenant, resource, or task context. This is also where agentic AI adds a new layer of concern: if an AI agent has tool access, then the application’s internal access checks effectively become part of the agent’s privilege boundary.
Best practice is evolving toward stronger policy-as-code, runtime validation, and continuous testing of authorisation paths, but current guidance suggests that no single control plane is enough. Security and app teams need to treat application logic as an access control surface, not just a software feature.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Applications can bypass central identity controls through local auth decisions. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement must exist in the application, not only in IAM tooling. |
| OWASP Non-Human Identity Top 10 | Machine identities often exploit app-level secrets and token handling gaps. |
Apply NHI governance to service accounts, API keys, and automation tokens used by applications.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
