Application attack rates surged to 87% as AI compresses attacker costs

At a glance

What this is: Application attack activity has climbed sharply, with hostile contact arriving within hours of publication and attack rates rising across every major vertical.

Why it matters: AppSec, IAM, and security teams need to assume shorter exposure windows, faster adversary automation, and tighter identity and secret controls around application runtimes.

By the numbers:

• Since 2022, the attack rate on enterprise applications has risen from 55% to 87%.
• 91% each.
• The largest single-year jump in attack rates for medical device apps moved from 78% to 86%.

👉 Read Arxan Technologies' 2026 Application Security Threat Report

Context

Enterprise application security now has to account for a much shorter window between release and attack. The primary issue is not just more malicious activity, but the collapse of time, cost, and skill barriers that once slowed adversaries. In practice, this means application protection, secrets control, and runtime monitoring need to be designed as one operating model, not separate functions.

The article's relevance to identity governance is indirect but real. When attackers can reverse-engineer apps quickly, exposed secrets, weak service account design, and permissive API access become faster routes from application compromise to identity abuse. That makes application security a feeder problem for IAM, PAM, and NHI governance, especially where mobile, cloud, and API-driven systems share credentials or trust chains.

Key questions

Q: How should security teams reduce the risk from public-facing application attacks?

A: Treat publication as the start of active defence, not the end of testing. Teams should combine pre-release secret scanning, runtime telemetry, rapid rollback, and token revocation so the first hostile contact does not become a foothold. The goal is to shrink the window in which exposed code, credentials, or APIs can be analysed and abused.

Q: Why do application secrets create identity risk as well as appsec risk?

A: Because secrets are machine credentials. If a token, API key, or certificate is embedded in an application, compromise of the app can become compromise of a downstream identity. That is why IAM and AppSec need shared ownership of secret scope, rotation, and revocation.

Q: What breaks when secrets are left in deployed applications?

A: Standing credentials turn a code issue into a trust issue. Attackers can reuse those credentials to call APIs, impersonate services, or move laterally into connected systems. Once the secret is exposed, patching the app alone does not remove the access path.

Q: How do security teams know if application hardening is keeping pace with attackers?

A: Measure the time from publication to hostile contact, the percentage of apps with embedded secrets, and the speed of revocation after exposure. If any of those metrics drift upward, attackers are gaining operational advantage faster than defenders are closing it.

Technical breakdown

Why AI compresses application attack economics

AI reduces the effort needed for reconnaissance, code analysis, and exploit development. What used to require specialist reverse-engineering can now be done faster with commodity tooling and an LLM subscription, which narrows the defender's lead time after publication. That changes the security model for both mobile and server-side applications: once the app is public, hostile analysis starts almost immediately. The practical issue is not whether an attacker is clever, but whether the application exposes enough structure, telemetry, or secrets to make quick exploitation possible.

Practical implication: assume every release enters an active attack window immediately and align monitoring, secret hygiene, and rollback readiness to that reality.

Why application secrets become identity risks

Application compromise often becomes an identity problem because secrets, API keys, tokens, and certificates are the bridge into downstream systems. If those credentials are embedded, reused, or poorly scoped, the attacker does not need a deeper exploit chain to move from app access to service access. This is where AppSec and IAM overlap: the application may be the entry point, but the real control failure is weak identity binding for machines and workloads. Stronger isolation, short-lived credentials, and scoped trust reduce the blast radius when code is inspected or tampered with.

Practical implication: inventory application-bound secrets and tie them to workload identity, not static embedded credentials.

What changing vertical attack rates signal about exposure patterns

When attack rates converge across sectors, it suggests adversaries are applying repeatable tooling rather than targeting only high-value industries. Banking, connected vehicles, medical devices, and consumer apps now face similar pressure because public distribution and exposed interfaces make them discoverable at scale. That makes security posture a function of runtime visibility, update velocity, and credential exposure, not just industry sensitivity. For organisations, the lesson is that any externally reachable app can become a staging point for broader identity abuse or data extraction.

Practical implication: prioritise runtime controls and attack-surface reduction based on exposure, not on the business label of the application.

Threat narrative

Attacker objective: The attacker aims to turn a public application into an access path for credential theft, service abuse, or downstream compromise.

1. Entry occurs when attackers target a newly published application and begin hostile analysis almost immediately after public release.
2. Credential access or abuse follows when exposed secrets, tokens, or API keys are identified in code, configuration, or connected services.
3. Impact occurs when the attacker uses the compromised application trust path to tamper with data, extend access, or pivot into adjacent systems.

NHI Mgmt Group analysis

AI has collapsed the attacker time-to-insight for exposed applications. The report's numbers point to a new baseline where publication and analysis are effectively simultaneous. That matters because traditional appsec models still assume a slower discovery cycle, leaving too much time for secrets, endpoints, and APIs to be probed before controls adapt. Practitioners should treat release-day hardening as a core operational requirement, not a post-release task.

Application security is now an identity governance problem whenever secrets are present. An externally attacked app becomes an IAM and NHI issue the moment its credentials, certificates, or tokens can be reused outside the intended runtime. This is why machine identity binding matters as much as code hardening. Runtime identity exposure window: the gap between application publication and the first moment an attacker can extract and abuse trust material. Teams that cannot shorten this window will keep losing downstream control.

The vertical convergence in attack rates shows adversaries are scaling tactics, not just targeting sectors. Banking, mobility, and medical-device applications are all being hit at levels that imply reusable tooling and repeatable reconnaissance. That should push security leaders to re-rank risk by exposure and privilege, not by brand sensitivity or regulated status. The practical conclusion is that any public app with shared trust relationships deserves the same control attention as a crown-jewel workload.

Secrets management remains the hinge between application compromise and broader identity abuse. Once an application leaks a token, the attacker no longer needs to stay inside the app boundary. This is why the control gap is not just patching or code review, but the presence of durable credentials that survive deployment. Teams should view secret lifetime, scope, and revocation speed as first-order governance metrics.

What this signals

Application teams should expect the attacker tempo to keep shrinking as AI-assisted reverse engineering becomes routine. That makes pre-release secret scanning, runtime telemetry, and revocation workflows part of deployment discipline rather than emergency response. For identity teams, the practical consequence is that workload identity and short-lived credentials become more valuable than any control that depends on a long review cycle.

Runtime identity exposure window: the period between public release and the first moment credentials can be extracted and reused is now a measurable risk metric, not a theoretical concern. Organisations that still rely on embedded secrets or broad API trust will find that exposure persists long after code goes live. Align application hardening with CISA cyber threat advisories and pair it with Top 10 NHI Issues where machine credentials are part of the service model.

For practitioners

• Shorten the release-to-monitoring gap Start runtime monitoring before public release, with alerting on first hostile contact, anomalous API calls, and secret extraction attempts in the first hours after publication.
• Bind application trust to workload identity Replace embedded secrets and long-lived tokens with workload identity and short-lived credentials wherever the application calls downstream services.
• Inventory exposed trust material across mobile and API surfaces Map tokens, certificates, keys, and third-party API credentials by application, then revoke or rotate anything that can survive outside its intended runtime.
• Prioritise controls by exposure, not by sector label Re-rank application hardening work based on public reachability, shared trust chains, and downstream privilege rather than whether the app sits in banking, healthcare, or mobility.

Key takeaways

• Application attack rates have risen sharply, and hostile analysis now begins within hours of publication.
• The control gap is no longer just code quality. It is the speed at which exposed secrets and trust material can be found and reused.
• Security teams should treat workload identity, short-lived credentials, and rapid revocation as core appsec controls, not optional hardening.

Key terms

• Identity Exposure Window: An identity exposure window is the period between when a credential or account becomes risky and when governance actually removes or contains it. The longer that window stays open, the more likely attackers can reuse the identity, escalate access, or turn a leak into a breach.
• Application Bound Secret: An application bound secret is a credential, token, key, or certificate that an application uses to authenticate to another service. When it is embedded, reused, or long-lived, compromise of the application can become compromise of the downstream identity it represents.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.

What's in the full report

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

• Telemetry methodology behind the billion-instance application dataset and how hostile contact timing was measured
• Vertical-by-vertical attack-rate breakdowns for banking, connected vehicles, medical devices, and mobile apps
• The report's publication-era threat patterns, including why AI has lowered the cost of reverse-engineering apps
• Operational context for teams deciding which application hardening controls to prioritise first

👉 The full Arxan Technologies whitepaper covers the telemetry evidence, vertical breakdowns, and attack-rate trends in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners align application trust, identity controls, and runtime risk management across modern environments.