Application attack rates surge as AI compresses the attacker cost curve

At a glance

What this is: This report shows that application attack rates are rising sharply while hostile contact now arrives within hours of publication.

Why it matters: It matters because IAM, NHI, and application security teams need to treat exposed app logic, tokens, and service integrations as early attack surfaces, not late-stage cleanup issues.

By the numbers:

• Since 2022, the attack rate on enterprise applications has risen from 55% to 87%.
• In 2026, iOS apps faced half Android’s attack rate in 2023, but the gap is under 3 points.
• 91% each.

👉 Read Arxan Technologies' 2026 Application Security Threat Report

Context

Application security is shifting from a release-time concern to a runtime exposure problem. Once an app is public, the first hostile contact can arrive almost immediately, which means attackers are no longer waiting for broad adoption before testing weak points. The report's central point is that AI has compressed the attacker cost curve as much as it has improved software delivery.

That matters for identity governance because modern apps are built on secrets, tokens, service integrations, and delegated access paths that are easy to overlook once code ships. When attacker tooling improves faster than application controls, teams need to think about identity-bearing components inside the application stack, not just user authentication at the edge.

Key questions

Q: How should security teams handle secrets found in application code?

A: Treat every secret in code as a governance issue, not just a coding mistake. Security teams should identify whether the secret is still valid, what systems it can reach, and whether it has been used elsewhere. Then rotate or revoke it, remove it from source control, and add build-time scanning so the same exposure does not recur.

Q: Why do public applications create such a short attack window?

A: Because attackers can discover and probe public releases immediately, often with automation and AI-assisted analysis. Once an app is accessible, exposed APIs, embedded secrets, and trust assumptions can be tested without waiting for broad adoption. That makes the earliest hours after publication the most important period for monitoring and containment.

Q: What do security teams get wrong about mobile and application secrets?

A: They often treat embedded secrets as implementation details instead of reusable access. In practice, a leaked token or API key can become a non-human identity with real privilege, especially if it reaches backend services, cloud resources, or partner integrations. Governance must follow the credential, not just the codebase.

Q: How can organisations limit damage when an app release is attacked quickly?

A: They should combine pre-release secret scanning, strict token scope, fast revocation, and runtime anomaly detection on exposed services. The goal is to shrink blast radius before attackers can chain reconnaissance into credential abuse. If release is already public, containment depends on rapid identity rotation and service-side control.

Technical breakdown

Why app store publication now starts the attack clock

Public release creates a predictable discovery window for attackers, especially when applications expose version metadata, network endpoints, embedded configuration, or reusable auth patterns. Real-world telemetry in the report shows hostile contact arriving within hours, which is consistent with automated scanning and rapid reverse engineering. AI lowers the effort needed to map an app’s logic, identify weak API handling, and extract secrets or tokens from client-side assets. The result is not just faster exploitation, but a shorter period in which defenders can assume obscurity buys safety.

Practical implication: treat public release as the start of exposure monitoring, not the end of testing.

How AI changes the economics of app reverse engineering

The report argues that a laptop and an LLM subscription now provide enough leverage to accelerate reverse engineering that once required specialised skills and time. That shifts the balance from expert-only attacks to more scalable, repeatable abuse of mobile and web app surfaces. For security teams, this means static protections alone are no longer enough if attacker reconnaissance and code comprehension can be automated. Application security programmes must therefore assume faster probing of APIs, embedded secrets, and client-side trust assumptions.

Practical implication: harden client-side trust assumptions and assume attacker reconnaissance is automated.

Why application identity and secrets matter more than ever

Applications increasingly depend on non-human identities such as API keys, service tokens, certificates, and backend credentials. When those are embedded in mobile clients, configuration files, or build artefacts, the app becomes both the delivery mechanism and the access path. This is where IAM and NHI governance intersect with application security: exposed secrets are not just code defects, they are identity defects that extend privilege into runtime systems and downstream services. That makes credential containment a core appsec control, not an adjacent concern.

Practical implication: inventory and protect app-linked secrets as identity assets, not as implementation details.

Threat narrative

Attacker objective: The attacker’s objective is to turn public application exposure into reusable access paths, exposed data, and downstream service compromise.

1. Entry begins with public app publication, which gives attackers a known target and immediate access to binaries, APIs, and metadata for inspection.
2. Escalation follows when AI-assisted analysis speeds reverse engineering of trust flows, embedded secrets, and weak client-side assumptions, enabling deeper access paths.
3. Impact occurs when exposed tokens, credentials, or API behaviours are reused to manipulate services, harvest data, or establish persistent access to backend systems.

NHI Mgmt Group analysis

AI has collapsed the attacker preparation phase, which makes public application exposure a governance problem rather than only a testing problem. The report's core signal is that hostile contact now happens within hours, not days. That shortens the defender's useful response window and changes what counts as timely control verification. For practitioners, this means release governance must include identity-bearing assets, secret exposure checks, and runtime monitoring before publication, not after the first abuse event.

Application security and identity governance are converging around secrets, tokens, and delegated access. An app that leaks credentials is not just poorly hardened, it is carrying identity material that can be reused outside intended boundaries. That creates a direct overlap between appsec, PAM, and NHI governance because the compromised object is often a non-human credential rather than a human account. Practitioners should treat application-linked identities as a governed population with lifecycle, scope, and revocation requirements.

Attack rates above 80% in many app categories show that defensive maturity is no longer measured by prevention alone. The report’s vertical comparisons suggest attackers are adapting faster than control baselines in several sectors, including mobile, connected vehicle, and medical device environments. That means the real question is whether teams can detect abnormal access patterns, contain exposed identities, and limit blast radius when publication inevitably becomes exposure. Practitioners should prioritise containment over confidence.

Adaptive attacker economics create a new named concept: exposure-to-abuse compression. This is the shrinking interval between a public release and meaningful hostile action, driven by AI-assisted reconnaissance and automation. Once that interval compresses, security assumptions built around delayed exploitation become unreliable. The practical conclusion is that application governance now needs pre-release identity review, secret scanning, and post-release telemetry as a single control chain.

Sector-specific attack convergence shows that application risk is becoming infrastructure risk. When connected-vehicle apps are attacked at the same rate as banking apps, the issue is not just code quality but the reach of the identities and services behind the app. That widens the governance conversation from AppSec teams to IAM, cloud security, and resilience stakeholders. Practitioners should manage app exposure as part of broader service identity control.

What this signals

Exposure-to-abuse compression: the gap between publication and hostile contact is shrinking so quickly that release processes now need identity controls baked in. For teams handling app-linked credentials, the operational question is not whether attackers will test the surface, but whether secret discovery and revocation happen before reuse. That is where runtime telemetry, pre-release review, and fast credential rotation become programme-level priorities.

The broader signal is that appsec, IAM, and cloud teams can no longer operate on separate clocks. Once a public release exposes tokens or service integrations, the issue becomes identity governance across a live attack surface, not a post-deployment vulnerability ticket. Practitioners should align release gating with NHI lifecycle controls and keep a close watch on delegated access paths.

For practitioners

• Shift secret discovery left of release Scan builds, client bundles, mobile packages, and CI artefacts for API keys, tokens, certificates, and backend credentials before publication. Block release when identity-bearing assets are detected.
• Treat application-linked identities as governed assets Assign ownership, scope, rotation, and revocation rules to app-linked service accounts and tokens so they are managed like other non-human identities across their lifecycle.
• Instrument post-release hostile-contact monitoring Watch for anomalous API probing, rapid reverse engineering signals, and suspicious authentication attempts in the first minutes and hours after app publication.
• Reduce client-side trust assumptions Move sensitive authorization decisions off the client where possible, and assume published binaries and app logic will be inspected quickly with AI-assisted tooling.
• Link AppSec and IAM review gates Require IAM or NHI review for any release that introduces new tokens, delegated access, third-party integrations, or service-to-service authentication paths.

Key takeaways

• Application attack rates have climbed sharply, showing that public release now triggers immediate adversarial attention rather than a delayed threat cycle.
• The most important control failure is not only code weakness but exposed identity material, because leaked secrets turn application risk into reusable access.
• Teams should combine pre-release secret review, rapid revocation, and post-release monitoring so that attack windows shrink before attackers can exploit them.

Key terms

• Exposure-to-abuse compression: The shrinking time between public exposure of an application and meaningful attacker action. It describes how automation and AI reduce the interval in which defenders can rely on obscurity or delayed exploitation, forcing security teams to move secret scanning, revocation, and monitoring earlier in the release cycle.
• Application-owned Identity: Application-owned identity is the pattern where authentication, session logic, tenant boundaries, and some lifecycle decisions are implemented inside the product rather than centrally in IAM. It gives teams flexibility, but it also increases governance burden because control quality depends on application code, configuration, and integration discipline.
• Client-side trust assumption: A design belief that the application running on a user device can safely hold secrets or make security decisions without being examined or altered. In practice, public binaries are easy to inspect, so sensitive authorization logic and reusable credentials should be moved out of the client wherever possible.

What's in the full report

Arxan Technologies' full report covers the operational detail this post intentionally leaves for the source:

• Vertical-by-vertical attack rate breakdowns for mobile, banking, connected-vehicle, and medical device environments.
• Telemetry methodology behind the first hostile contact timing and how the report measures early abuse patterns.
• Additional trend data on regional shifts across EMEA, LATAM, APAC, and North America.
• Context on how AI changes attacker workflow and the economics of reverse engineering.

👉 Arxan Technologies' full report covers the telemetry, vertical comparisons, and regional attack-rate shifts in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, identity lifecycle, and secrets management. It helps practitioners connect identity controls to the operational realities of modern security programmes.