Should organisations treat identity controls as part of application security?

Yes, because the practical exploit path often depends on identity scope, not just code quality. Application security that ignores service accounts, tokens, and inter-service permissions leaves the most important trust boundaries untested. The right model is cross-functional: appsec validates the logic, while IAM and NHI governance validate the authority the application actually has.

Why This Matters for Security Teams

Yes. Treating identity controls as outside application security creates a gap between what the code does and what the application is allowed to do. Modern applications rarely act alone. They call APIs, assume roles, exchange tokens, and rely on service identities that can be over-permissioned, stale, or never reviewed. That means an apparently clean codebase can still expose sensitive data or infrastructure through weak authorisation design.

This is why current guidance, including the NIST Cybersecurity Framework 2.0, aligns security outcomes to broader governance, access control, and resilience objectives rather than code testing alone. In practice, application security teams that focus only on input validation, dependency scanning, and static analysis often miss the trust relationships that attackers actually abuse. Identity scope determines blast radius, especially in cloud and microservice environments where machine-to-machine access is the default.

The practical issue is ownership. Appsec may own secure design and testing, but if IAM and NHI governance are excluded, no one is validating whether the application has the right to use the secrets, tokens, and privileges it already holds. In practice, many security teams encounter this only after a token leak or lateral movement event has already exposed the real attack path, rather than through intentional design review.

How It Works in Practice

Identity controls become part of application security when they are built into design review, threat modelling, testing, and deployment gates. The question is not only whether an application is vulnerable to injection, but whether a successful exploit would grant access to data, functions, or systems beyond the intended scope. That requires reviewing both human and non-human identities, because service accounts, workload identities, and automation tokens often carry the most powerful permissions.

A practical approach is to map the application’s trust boundaries and then trace every identity that crosses them. Security teams should verify who or what can authenticate, what each identity can read or change, how tokens are issued and stored, and whether privileges are time-bound or persistent. This is where appsec and IAM overlap: appsec tests the application’s behaviour, while identity governance checks whether the application’s authorised actions are appropriately limited.

• Inventory service accounts, API keys, certificates, and federated identities used by the application.
• Review token scope, rotation, expiry, and storage location as part of release approval.
• Test for broken authorisation, privilege escalation, and insecure service-to-service trust.
• Log identity events alongside application telemetry so abuse can be detected and triaged faster.
• Use least privilege and separation of duties for CI/CD, runtime, and administrative access.

For control mapping, the Zero Trust Architecture guidance is useful because it assumes identity verification and continuous policy enforcement across every request, not just at the network perimeter. That matters in environments where apps call apps, because the weakest identity often becomes the attacker’s easiest pivot. These controls tend to break down when legacy applications share static credentials across many services because attribution, rotation, and least-privilege enforcement become operationally inconsistent.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance security assurance against delivery speed and platform complexity. That tradeoff is real, especially in fast-moving engineering environments where teams want short-lived access, automated provisioning, and minimal manual review. Best practice is evolving, but there is no universal standard for exactly how much identity data appsec must own versus IAM or platform teams.

Some environments need additional nuance. In serverless and container platforms, workload identity may be ephemeral, so static credential review is less useful than policy-as-code, runtime attestation, and secretless authentication. In outsourced or shared-service models, application owners may not directly control the underlying identity system, which makes contractual accountability and logging more important. In regulated payment environments, identity scope also affects fraud and audit evidence, so the boundary between application security and access governance becomes even more explicit. The OWASP guidance on broken access control is relevant here because the most damaging failures often arise when authorisation logic and identity trust assumptions drift apart.

For organisations adopting zero trust, the practical test is simple: if an attacker gets one application credential, what else can that credential reach? If the answer is unclear, identity controls are not being treated as part of application security yet.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• How should organisations align IT application controls with identity governance?
• How should security teams implement GRC so identity controls are part of it?
• Should organisations evaluate AI agent security tools before or after identity controls are in place?