Should organisations rebalance investment from identity controls to application security?

Why This Matters for Security Teams

Budget decisions between identity and application security are really decisions about where the organisation is absorbing risk. Identity controls reduce blast radius when attackers reuse credentials, hijack sessions, or move laterally through privileged access. Application security reduces the number of exploitable paths into the environment in the first place. The mistake is treating these as competing programmes instead of layers that fail differently.

The practical issue is that many organisations overfund control points that are easier to audit, while underfunding the teams that find and fix exploitable flaws before release. That creates a security posture that looks mature on paper but still allows routine exploitation through vulnerable web apps, APIs, dependencies, and misconfigurations. A useful lens is the NIST Cybersecurity Framework 2.0, which frames risk treatment across governance, protection, detection, and response rather than a single control domain.

In practice, many security teams encounter identity compromise only after application weakness has already provided the first foothold.

How It Works in Practice

A sensible rebalance starts with exposure data, not intuition. If applications, APIs, and third-party components are producing the majority of reachable attack paths, then investment should shift toward secure development, vulnerability management, testing, and faster remediation. If identity misuse, token theft, or privilege abuse is the dominant failure mode, then identity governance, PAM, MFA hardening, session control, and NHI governance remain central. The right answer is usually a proportionate mix based on observed attack paths, not a fixed percentage split.

Operationally, security leaders should map where controls stop attacks versus where they only limit damage. Application security is strongest when it prevents vulnerable code, insecure dependencies, and exposed secrets from reaching production. identity security is strongest when it constrains what an attacker can do after initial access. That division matters because modern incidents often chain the two together: an application flaw yields access, and weak identity controls turn that access into persistence.

• Use threat modelling to identify whether the primary path is code exploit, credential abuse, or both.
• Prioritise remediation by exploitability and asset criticality, not by scan volume alone.
• Instrument detection around authentication abuse, token anomalies, and privilege escalation.
• Align application findings to release gates and patch SLAs so remediation is measurable.

For application risk, NIST guidance on vulnerability management and secure development pairs well with OWASP’s testing and input-validation principles, while CISA’s Known Exploited Vulnerabilities Catalog helps teams focus on issues attackers are actually using. For identity-heavy environments, this should be linked back to strong authentication, privileged access review, and secret rotation, especially where applications mint or consume long-lived tokens. These controls tend to break down when legacy applications cannot support modern authentication, because teams then preserve insecure exceptions rather than redesigning the access path.

Common Variations and Edge Cases

Tighter application security often increases engineering overhead, requiring organisations to balance delivery speed against reduction in exploitable exposure. That tradeoff becomes sharper in fast-moving product teams, regulated environments, and systems with heavy third-party dependency chains.

Current guidance suggests there is no universal standard for how much to shift from identity to application security, because the answer depends on whether the organisation is mainly defending against exploitation, credential abuse, or supply-chain compromise. In cloud-native environments, application-layer failures and identity-layer failures frequently overlap, especially where CI/CD pipelines, service accounts, and secrets management are weak. In those cases, rebalance should include both code-level controls and NHI governance rather than treating runtime identities as a separate concern.

Some edge cases deserve special handling. If the organisation is highly regulated or processes payments, application fixes may be prioritised for compliance reasons as much as risk reasons, especially where OWASP Top 10 classes of weakness create known exposure. If the environment relies on SaaS platforms or third-party APIs, then control ownership may sit outside the application team, which means contractual assurance, monitoring, and compensating identity controls matter more. The best programmes revisit the balance quarterly, using incident trends and exposure metrics rather than static budget lines.

Related resources from NHI Mgmt Group

• Should organisations treat identity controls as part of application security?
• How should organisations align IT application controls with identity governance?
• Should organisations evaluate AI agent security tools before or after identity controls are in place?
• When should organisations prioritise browser security over other identity controls?