Why IAM Architects Prescribe Enterprise Application Security

Most enterprise application security programs still treat identity as a checkbox: a login screen, a password policy, an SSO integration, done. That is why breaches keep landing in the same place. If you have budget for one thing this quarter, spend it on authorization logic and credential handling inside your applications, not on another scanner.

I write this as someone who built a customer identity platform. I founded LoginRadius and scaled it past a billion user identities, which means I spent a decade reading other companies' application architectures during security reviews and migrations. The pattern almost never changed. The authentication was fine. The authorization was improvised.

What changed between 2021 and 2026

Three shifts matter for anyone designing an application security program today.

The OWASP Top 10 was rewritten. The OWASP Top 10:2025, announced at Global AppSec in November 2025, put Broken Access Control at A01 and promoted Security Misconfiguration to A02. Server-side request forgery was folded into Broken Access Control. Two categories are new: Software Supply Chain Failures at A03 and Mishandling of Exceptional Conditions at A10. "Identification and Authentication Failures" was renamed to Authentication Failures and sits at A07.

Read that list as an identity architect and the message is blunt. The number one and number seven risks in the world's most-cited application security list are both identity problems, and the number one has been an identity problem for two consecutive editions.

The initial-access story moved, but the identity story did not. The Verizon 2026 Data Breach Investigations Report found that vulnerability exploitation started 31% of breaches, displacing credential abuse as the top initial access vector for the first time in the report's history. Credential abuse still appears somewhere in the chain of roughly four breaches in ten. Attackers get in through a bug and then move using identity. Fixing only the entry point leaves the rest of the attack path intact.

Non-human identity became the majority. Palo Alto Networks' 2026 Identity Security Landscape, a survey of 2,930 security decision-makers, put the ratio of machine identities to human identities at 109 to 1, up from 82 to 1 a year earlier. Other counts published in 2026 range from 45 to 1 to over 100 to 1. The exact number is less useful than the direction: the identities inside your applications now vastly outnumber the people using them, and almost none of them have an owner, a rotation schedule, or a deprovisioning path.

The vulnerabilities an IAM architect looks for first

When I review an enterprise application, I start in four places, in this order.

1. Object-level authorization

Authentication answers "who is this". Authorization answers "may this person do this, to this record, right now". Broken access control is A01 because the second question is usually answered by scattered if-statements in controllers rather than by a policy the team can read, test, and audit. The tell is simple: ask an engineer to show you, in one place, every rule that governs who can read a given object. If they cannot, you have a finding.

2. Session and token handling

Long-lived access tokens, refresh tokens with no rotation, JWTs validated without checking the issuer or audience, and session identifiers that survive a password reset. These are the mechanics that turn one stolen credential into persistent access. Tokens are also where machine identity hides: service accounts and integration keys are frequently issued once and never touched again.

3. Secrets and the supply chain

Software Supply Chain Failures earned its own OWASP category in 2025 for a reason. Credentials committed to repositories, build systems with standing cloud permissions, and third-party packages pulled at build time without pinning are all identity failures wearing a build-pipeline costume. The credential in the pipeline usually has more privilege than any human in the company.

4. Misconfiguration and error handling

Default admin consoles, permissive CORS, storage buckets open to the internet, verbose stack traces that leak internal hostnames. Mishandling of Exceptional Conditions is new at A10 and covers the last of those: what your application does when something unexpected happens, including whether it fails open on an authorization check. Fail-open authorization is the single most dangerous bug class I have seen in production identity code.

Where the tooling actually helps

The 2021 version of this advice named static testing, dynamic testing, and runtime self-protection. That taxonomy still works, but the emphasis has moved.

Layer	What it catches	What it misses
SAST (static analysis)	Injection, unsafe crypto calls, hardcoded secrets	Business-logic authorization flaws
DAST and API testing	Exposed endpoints, misconfiguration, auth bypass on known routes	Anything behind an undocumented endpoint
SCA and SBOM	Known-vulnerable dependencies, license risk	Unknown flaws introduced by a trusted upstream
ASPM	Correlation across the above, ownership, policy gates in CI	Runtime behaviour of a live session
Runtime protection (RASP and successors)	Live exploitation attempts, blocking in production	Design flaws; it is a shock absorber, not a fix
ITDR and identity analytics	Anomalous session and token use, dormant machine identities	Code defects

Two practical notes. First, no scanner in that table reliably finds a broken object-level authorization check, because the tool has no way to know which user was supposed to see which record. That defect class is found by design review and by tests you write yourself. Second, runtime protection is still worth having on legacy applications you cannot safely refactor, but treat it as compensating control with an expiry date, not as a security architecture.

The standards worth citing in your own requirements

If you are writing security requirements for an internal build or an RFP, anchor them to published standards instead of vendor marketing.

• NIST SP 800-63-4, finalised on 31 July 2025 after almost four years and roughly 6,000 public comments. Revision 4 formally admits syncable authenticators (synced passkeys) at AAL2 under stated conditions, including an end-to-end encrypted sync channel and user verification at the point of use.
• OWASP ASVS 5.0, released 30 May 2025. It is the most useful single document for turning "make it secure" into testable requirements, with roughly 350 requirements across 17 categories and stable identifiers you can reference in tickets.
• OWASP Top 10:2025 for prioritisation and board-level framing, not as a compliance checklist. It describes what is common, not what is critical in your system.
• FIDO2 and WebAuthn for the authentication layer. The FIDO Alliance reported roughly five billion passkeys in use as of World Passkey Day 2026, with 75% of surveyed consumers having enabled a passkey on at least one account. Phishing resistance is no longer an exotic requirement.

The machine identity problem you are probably deferring

Most application security programs have a credible plan for human identity. Very few have any plan for the service accounts, API keys, CI tokens, and now AI agents operating inside the same applications. The agent case is the sharpest version of an old problem: software acting with delegated authority, at machine speed, using a credential nobody can attribute to a person.

The minimum viable answer has not changed since service accounts were invented. Every non-human identity needs a named human owner, a scoped permission set, an expiry, and a log that survives the credential. What has changed is the volume. At 100 machine identities per employee, doing this by hand is not an option, so it has to be a property of how applications are built, not a quarterly clean-up project.

What I would do in the first 90 days

1. Inventory the authorization decisions, not the applications. List every place your code decides whether a subject may act on an object. That list is your real attack surface.
2. Write authorization tests before adding tools. One test per role per sensitive object, asserting both the allow and the deny. Most teams have never written the deny case.
3. Kill standing credentials in the build pipeline. Short-lived, workload-scoped tokens issued per job. This single change removes the most valuable credential in most organisations.
4. Move the login layer to phishing-resistant authentication for administrators first, then for customers. Passkeys at AAL2, per SP 800-63-4.
5. Give every machine identity an owner and an expiry date. Start with anything holding production write access.
6. Instrument for identity, not just for errors. Security Logging and Alerting Failures is still on the OWASP list at A09. If you cannot reconstruct which token performed an action, you cannot run an investigation.

How I verified this

Every claim above was checked in September 2026 against its primary source. The sources checked were the OWASP Top 10:2025 and ASVS 5.0 project pages, and the NIST SP 800-63-4 publication pages. Also the Verizon DBIR page for the 2026 edition, the Palo Alto Networks 2026 Identity Security Landscape page, and the FIDO Alliance report for World Passkey Day 2026. Statistics from vendor surveys are labelled as surveys, because they measure what respondents believe about their own environments.

Last verified: September 2026.

Frequently Asked Questions

Is application security an IAM problem or an AppSec problem?

Both, and the split is the problem. Authentication usually belongs to the identity team, while authorization logic lives in application code owned by product engineering. Breaches happen in the gap. The fix is a shared, reviewable policy layer rather than a shared Slack channel.

Does buying a CIAM or IAM platform make my applications secure?

No. A CIAM platform handles registration, authentication, session issuance, MFA, and consent well. It cannot tell your order-management API which customer is allowed to read which order. That decision stays in your code unless you deliberately externalise it to a policy engine.

Is RASP still worth buying in 2026?

It is a reasonable compensating control for applications you cannot modify quickly, and vendors still ship it, often folded into broader runtime and posture platforms. It is not a substitute for fixing an authorization defect, and budget is better spent on ASPM plus authorization testing if you must choose.

What single metric shows whether the program is working?

Time from discovery to fix for access-control defects specifically, tracked separately from the general vulnerability backlog. Mean time to remediate across all findings hides the class that actually causes breaches.

How do AI agents change the requirements?

They do not introduce a new category, they multiply an existing one. An agent is a non-human identity with delegated authority and unusually broad reach. Scope its permissions per task, give it short-lived credentials, and log its actions in a way that ties back to the human who delegated to it.

Where should a small team start?

Two things: phishing-resistant authentication for anyone with production access, and a written authorization model for your top three data objects. Everything else can wait a quarter.

Related reading

• Secure coding practices: principles, vulnerabilities, and verification
• Tips for a successful DevSecOps life cycle
• IAM vs CIAM: which solution is right for you
• Fine-grained authorization patterns and token lifetime best practices