TL;DR: The OWASP Top 10 2025 release candidate shifts AppSec away from symptom-level labels toward root causes, with changes such as splitting supply chain failures, elevating misconfiguration, and reframing access control and integrity issues, according to Orca Security and OWASP project leaders. That shift matters because identity, configuration, and provenance controls now sit at the centre of application risk, not beside it.
At a glance
What this is: This is Orca Security’s analysis of the OWASP Top 10 2025 release candidate, which recasts appsec around root causes such as broken access control, misconfiguration, supply chain failures, and integrity issues.
Why it matters: It matters because IAM, NHI, and application teams now have to treat access, provenance, and configuration as linked control problems rather than isolated findings.
By the numbers:
- A03:2025 Software Supply Chain Failures has more than 215,000 occurrences, according to Orca Security.
- A02:2025 Security Misconfiguration covers over 719,000 mapped CWEs, according to Orca Security.
- A04:2025 Cryptographic Failures has over 1.6 million occurrences, according to Orca Security.
- A05:2025 Injection affects 100% of tested applications, according to Orca Security.
Context
The OWASP Top 10 2025 release candidate is less about a new list than a new way of describing application risk. In practice, it shifts attention from symptom labels to the underlying control failures that create exposure across code, cloud, APIs, and identity boundaries.
For IAM and NHI teams, that matters because many appsec findings now map directly to access control, misconfiguration, provenance, and authentication problems. The article’s central message is that the boundary between application security and identity governance is shrinking, not widening.
The update also reflects a more operational view of risk. Instead of treating supply chain, integrity, logging, and exceptional conditions as separate technical silos, the model groups them around failure modes that security teams can actually govern across the lifecycle.
Key questions
Q: What breaks when broken access control is treated as a purely application-layer issue?
A: Teams miss the service and token boundaries where authorization actually fails. In modern applications, privilege is often expressed through APIs, workload tokens, and internal calls, so a user-centric view leaves the real trust path unprotected. Security teams need to test where authorization is enforced, inherited, and bypassed across the application stack.
Q: Why do misconfiguration problems keep resurfacing in cloud and application stacks?
A: Because configurable systems inherit unsafe defaults unless hardening is automated and continuously checked. When permissions, services, and accounts are left broad, the control failure is not a single mistake but a repeatable governance gap across environments.
Q: How should teams distinguish supply chain failures from software integrity failures?
A: Supply chain failures describe how risk enters through dependencies, build tooling, or update channels. Integrity failures describe whether the application verifies what it receives, such as unsigned code, unvetted plugins, or tampered data.
Q: Should IAM teams treat appsec root causes as part of their own programme?
A: Yes, because access control, configuration, and provenance now shape the same exposure path. If IAM ignores service permissions, token handling, and trust in software delivery, it leaves key parts of application risk outside governance.
Technical breakdown
Broken access control now includes service-level trust failures
OWASP’s A01:2025 category keeps broken access control at the top because modern applications blur user, service, and workload permissions. Server-side request forgery is now mapped into this area because it can let one service reach resources it should not control, turning network trust into unauthorized access. The important technical point is that access control is no longer only a UI or session problem. It is also a backend trust problem spanning APIs, tokens, and service-to-service paths.
Practical implication: review backend authorization paths, not just user-facing permissions.
Security misconfiguration is now a first-order control failure
A02:2025 treats misconfiguration as a broad root cause rather than a narrow deployment mistake. The category covers exposed default accounts, unnecessary services, insecure permissions, missing headers, and cloud storage that is open by accident or by drift. Technically, this is a governance problem because configurable systems tend to inherit unsafe defaults unless hardening is automated and continuously verified. Misconfiguration becomes especially dangerous when identity and resource permissions are left too broad across environments.
Practical implication: enforce repeatable hardening and configuration verification across all environments.
Supply chain and integrity failures split build trust from artifact trust
A03:2025 expands supply chain failures to cover build, distribution, update, and tooling compromise, while A08:2025 focuses on whether code or data can be trusted once delivered. That distinction matters: supply chain issues describe how malicious or altered software enters the pipeline, while integrity failures describe what happens when an application accepts unsigned or unverified artifacts. Together they show why provenance, signing, and change tracking now sit at the centre of application assurance.
Practical implication: treat build provenance and artifact integrity as separate controls with separate checks.
Breaches seen in the wild
- Twilio TaskRouter SDK compromise 2020: A bucket policy letting any AWS principal write let attackers swap Twilio's TaskRouter JS SDK for a malvertising version for about nine hours.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OWASP Top 10 2025 is really a control taxonomy update, not a cosmetics refresh: the list now aligns more closely with how failures propagate across identity, cloud configuration, and software provenance. That makes the document more useful to practitioners because it names the control surface where exposure starts, not just the symptom that appears at the end. The implication is that appsec and IAM programmes need shared governance language for access, configuration, and integrity.
Broken access control is increasingly an identity and workload boundary problem: the article shows that SSRF, token manipulation, and privilege escalation are now intertwined with backend trust paths. In operational terms, that means least privilege cannot stop at user accounts or console roles. The control has to extend into service permissions, API authorisation, and the way workloads are allowed to reach one another.
Security misconfiguration is the clearest example of root-cause thinking in this update: the risk is not one bad setting, but the absence of governed defaults across rapidly changing environments. That is why cloud permissions, exposed accounts, and insecure configuration drift are now central to appsec reporting. For practitioners, the lesson is that configuration control is an identity problem as much as a platform problem.
Software supply chain failures and software or data integrity failures should not be collapsed into one bucket: the former is about how risk enters through dependencies, build tooling, and update channels, while the latter is about whether the delivered artifact can be trusted. That distinction is important for governance because the right control is different at each stage. The result is a more precise model for code provenance, release assurance, and dependency oversight.
Identity blast radius: this update shows that access, provenance, and observability now shape the blast radius of an application as much as code quality does. When logging, alerting, and exception handling are treated as root causes rather than afterthoughts, they become part of the same control plane as authentication and authorization. Practitioners should therefore measure appsec readiness across the full path from identity issuance to runtime detection.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Workforce Identity Security Guide
What this signals
OWASP Top 10 2025 makes identity governance more operational: the most useful reading of the update is that application security controls now depend on the same governance disciplines used in IAM and NHI programmes. Access, configuration, and provenance are no longer separate reporting lines when one failure can cascade into the next.
Identity blast radius: the article’s real signal is that modern app risk spreads through permissions, service trust, and software provenance at the same time. That means practitioners should evaluate whether their governance model can connect authorization decisions, configuration drift, and release assurance in one control narrative.
For practitioners
- Align appsec findings to root causes Map findings to broken access control, misconfiguration, supply chain failure, cryptographic failure, and integrity failure so remediation targets the control gap rather than the symptom.
- Tighten backend authorisation paths Review service-to-service permissions, token handling, and SSRF-exposed paths to make sure backend trust does not bypass intended access controls.
- Automate environment hardening checks Use repeatable configuration baselines and verification across cloud, container, and application environments to catch default accounts, open permissions, and insecure settings before release.
- Separate provenance from integrity controls Track build provenance, signed releases, and artifact verification as distinct checkpoints so dependency compromise and tampering are not treated as the same failure.
Key takeaways
- OWASP’s 2025 update reframes application security around underlying control failures rather than symptom labels, which is more useful for governance and remediation.
- The biggest risk areas in the article are access control, misconfiguration, supply chain failure, cryptographic failure, and integrity failure, all of which map to operational controls.
- Teams will get better outcomes if they manage authorization, configuration, and software provenance as one connected risk surface instead of separate security tickets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, OWASP SAMM, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | The article links broken access control to backend service and API trust paths. |
| Recommendation — Review API authorization paths to stop backend trust failures from bypassing access controls. | ||
| OWASP ASVS | V8 — Authorization | Broken access control and token misuse map directly to application authorization requirements. |
| Recommendation — Use V8 to verify that authorization is enforced server-side across user and service paths. | ||
| OWASP SAMM | Design — Design Security | The article emphasises root causes that start in design and architecture, not only implementation. |
| Recommendation — Embed root-cause threat modeling and security requirements into design reviews. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Misconfiguration, integrity, and logging failures all depend on basic protective controls. |
| Recommendation — Harden configurations, protect logs, and verify integrity as part of baseline security hygiene. | ||
| SLSA | L3 — Build provenance and tamper resistance | The article’s supply chain discussion centres on signed, immutable builds and trusted release paths. |
| Recommendation — Adopt build provenance checks and signed artifacts to reduce software supply chain compromise. | ||
Key terms
- Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
- Security Misconfiguration: Security misconfiguration is a control failure caused by unsafe defaults, incorrect settings, or overly broad permissions in systems and pipelines. In NHI environments, it often shows up as exposed secrets, persistent roles, or permissive cloud templates. The risk is that routine automation becomes a durable access path.
- Software Supply Chain Failure: A software supply chain failure is any breakdown in the build, dependency, signing, or distribution chain that allows tampering, compromise, or unauthorized access. For NHI security, the concern is not only corrupted code but also the credentials and machine identities that move that code through the pipeline.
- Software Or Data Integrity Failure: A software or data integrity failure happens when a system trusts an artifact, update, or payload without verifying that it is authentic and unchanged. The risk is especially high in CI/CD, package delivery, and runtime updates where unsigned or tampered inputs can be executed as trusted code.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org