TL;DR: Application attack rates climbed from 55% in 2022 to 87% in 2026, with first hostile contact arriving 1 hour and 56 minutes after app store publication, according to Arxan Technologies' 2026 Application Security Threat Report. AI is shrinking the cost and skill barriers for app reverse engineering faster than most enterprise defence models are adapting.
At a glance
What this is: Arxan Technologies says enterprise application attack rates rose to 87% in 2026, and attackers now make first contact within 1 hour and 56 minutes of store publication.
Why it matters: This matters because the offensive lifecycle is now faster than many application protection and release governance models, forcing teams to harden binaries, telemetry, and runtime controls earlier.
By the numbers:
- Since 2022, the attack rate on enterprise applications has risen from 55% to 87%.
Context
AI has reduced the cost and skill barrier for reverse engineering and application abuse, which changes the economics of defending software after release. In practical terms, the problem is no longer only secure build pipelines or pre-release testing, but the speed at which exposed apps are profiled, tampered with, and attacked once public.
For identity security teams, the governance implication is that application access, token handling, and embedded secrets can no longer be treated as static at launch. The article’s figures point to a world where runtime protections, entitlements, and credential exposure in applications need continuous review rather than release-time assurance.
Key questions
Q: What breaks when applications are reverse-engineered soon after release?
A: The main failure is assuming release-time testing is enough. Once an app is public, attackers can analyse logic, extract secrets, and probe trust paths faster than many organisations can detect abuse. That means static controls lose value quickly and runtime resistance, tamper detection, and secret minimisation become the real protection boundary.
Q: Why does AI increase the risk of application abuse?
A: AI reduces the time and expertise needed to analyse software, which lowers attacker cost and raises attack volume. It lets hostile actors scale binary inspection, automate probing, and identify weak control paths sooner. The result is not magical exploitation, but a much cheaper and faster path to the same outcomes.
Q: How do teams know if mobile app hardening is actually working?
A: Look for reduced success in reverse engineering, fewer successful tampering attempts and cleaner separation between legitimate user traffic and suspicious API requests. If attackers can still extract logic or reach backend services through repackaged clients, the hardening layer is not holding. Measurement should focus on attack cost and trust quality, not only alert counts.
Q: What should teams do when app credentials are embedded in software?
A: Treat embedded credentials as a governance problem, not just a code smell. They should be inventoried, owned, scoped tightly, and replaced with short-lived or externally managed credentials where possible. If the app exposes secret material publicly, the downstream service must be assumed at risk as well.
Technical breakdown
How AI changes application reverse engineering economics
Application reverse engineering used to require specialist time, tooling, and patience. AI shortens that work by helping attackers analyse binaries, infer logic paths, and generate probes faster than manual methods allowed. That does not make every attack fully autonomous, but it does lower the cost of discovering weak points and scaling attempts across many targets. The practical effect is a broader attacker pool and shorter dwell time between publication and first hostile contact. Defensive assumptions built around slow, bespoke analysis are now misaligned with the pace of modern app abuse.
Practical implication: move from periodic assurance to continuous detection and runtime resistance once an app is exposed.
Why store publication now starts the attack clock
The moment an application is published, it becomes observable, downloadable, and testable by hostile actors. Store visibility gives attackers a clean entry point for fingerprinting, traffic replay, tampering attempts, and control bypass testing. That is especially important for mobile and connected-device apps, where code is distributed to endpoints outside the enterprise perimeter. The article’s telemetry suggests defenders can no longer treat publication as a neutral distribution event. It is now the start of an active adversarial validation phase.
Practical implication: treat app release as the beginning of threat exposure and align monitoring, tamper detection, and abuse controls accordingly.
Where application governance intersects with identity and secrets
Applications often carry API keys, tokens, certificates, and other credentials that attackers can extract once code or runtime behaviour is examined. That creates an identity problem as much as a software problem, because secrets and embedded authorisation paths become reusable access material. If those credentials are long-lived or over-scoped, a single exposed app can become a pivot into back-end services and data. This is where application security and NHI governance meet: the attack surface includes non-human credentials embedded in software and the services they unlock.
Practical implication: inventory embedded secrets and workload credentials as part of app hardening, not as a separate identity task.
Threat narrative
Attacker objective: The attacker wants to turn public application artefacts into reusable access paths, weaker controls, or manipulation opportunities.
- Entry begins when a newly published application is exposed to hostile probing immediately after release.
- Credential or logic harvesting follows as attackers reverse-engineer the app, identify exposed secrets, and map trust paths.
- Impact occurs when the attacker uses that understanding to tamper with the app, replay calls, or reach downstream services with abused credentials.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
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
AI has collapsed the attacker cost curve for application abuse. The article shows that reverse engineering and hostile validation are no longer slow, specialist tasks. That matters because application security models still often assume attackers need significant time and expertise before a product becomes materially exposed. Practitioners should now treat post-release abuse as an expected operating condition, not an edge case.
Application security is becoming an identity problem. As apps expose tokens, API keys, and service credentials, the real risk is often not just code tampering but credential reuse against downstream systems. That creates a non-human identity governance issue inside software delivery, where embedded secrets behave like standing access. The field needs better separation between application hardening and the governance of the credentials those applications carry.
Attack rates are now a useful proxy for control debt. Rising attack frequency across verticals suggests that release pipelines are outrunning runtime defenses. The useful question is no longer whether an app can be shipped securely, but whether it can remain resistant once it is public. Security teams should interpret the rising rates as evidence that visibility, tamper resistance, and secret exposure controls are lagging the threat model.
Mobile and connected-device applications deserve the same governance discipline as core infrastructure. The report’s vertical pattern shows that apps once treated as peripheral now face attack pressure comparable to banking and other high-value targets. That means application trust assumptions need to be reviewed as aggressively as privileged access or cloud workload trust. Practitioners should align app protection with NIST CSF and, where machine credentials are embedded, OWASP NHI thinking.
First hostile contact is now a design constraint, not a post-incident metric. A sub-two-hour window between publication and first contact changes how teams think about release readiness. The governance challenge is not just detection after compromise, but the probability that a fresh release is already under attack before internal teams have completed normal operational checks. Security programmes should use that window to set expectations for telemetry, response, and hardening.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: Threat Modelling AI Agents
What this signals
AI has changed application exposure from a release event into a continuous adversarial process. The practical shift for teams is that every public build now has to be assumed testable, inspectable, and abuseable almost immediately after exposure. That pushes runtime telemetry, tamper detection, and short-lived trust material to the front of the control stack.
Application governance now overlaps with NHI governance. When apps carry API keys, certificates, and service tokens, those credentials become part of the application attack surface and not just the back end’s problem. Teams that still separate code security from non-human credential governance will miss the fastest path to downstream compromise.
For practitioners
- Harden applications before release Build tamper resistance, code obfuscation, and anti-reverse-engineering checks into release criteria so public binaries expose less usable intelligence.
- Inventory embedded credentials and tokens Treat API keys, certificates, session tokens, and service credentials inside apps as governed non-human identities with ownership, scope, and rotation tracked.
- Instrument runtime abuse detection Monitor for abnormal reverse-engineering signals, replay behaviour, and repeated abuse from newly published versions within the first exposure window.
- Shorten secret lifetime in distributed software Replace long-lived embedded secrets with short-lived credentials and tightly scoped trust paths so extracted material has less reuse value.
Key takeaways
- AI has compressed the attacker economics around application reverse engineering, which makes post-release abuse a baseline risk rather than an exception.
- The report’s 87% attack rate and 1 hour 56 minute first-contact window show that exposure now begins almost immediately after publication.
- Security teams need runtime resistance, embedded credential governance, and faster abuse detection if they want release controls to matter in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centers on reverse engineering, secret harvesting, and downstream abuse paths. |
| Recommendation — Map public-app abuse to TA0006 and TA0008, then prioritise telemetry that detects harvested trust paths. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Embedded tokens and exposed trust paths in apps create authentication abuse opportunities. |
| Recommendation — Review app-facing authentication flows for token exposure and weak validation under API2. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article’s identity angle is the exposure of API keys, tokens, certificates, and other embedded secrets. |
| NHI-07 — Long-Lived Secrets | Long-lived embedded credentials are especially damaging once public binaries are examined. | |
| Recommendation — Inventory embedded application secrets and eliminate leakage paths that turn code into reusable access material. Replace long-lived embedded secrets with short-lived credentials and constrained issuance paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core governance issue is whether exposed application trust paths are properly scoped. |
| Recommendation — Tighten entitlements and authorisations so public app exposure cannot translate into broad downstream access. | ||
Key terms
- API Reverse Engineering: API reverse engineering is the process of analysing an API to understand how it works, what endpoints it exposes, and how requests are structured. Attackers use it to bypass client applications, discover hidden functions, and find weaknesses in authentication, authorisation, or data handling.
- Runtime Resistance: Runtime resistance is the set of controls that make a deployed application harder to inspect, tamper with, or abuse while it is running or publicly distributed. It includes anti-tamper, anomaly detection, and controls that reduce the value of reverse engineering after release.
- Embedded Secret: An embedded secret is a credential, token, API key, or certificate that has been placed inside an image, file, or configuration bundle. Once exposed, it can outlive the original control that created it, so revocation and rebuilds become necessary even if the underlying system is later patched.
- Attack Surface View: An Attack Surface View is a consolidated view of externally reachable or security relevant assets that may be exposed to abuse. In API programmes, it helps teams see which services are present, how they relate to each other, and where sensitive data or higher risk paths are likely to exist.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners align credential governance with the systems that now carry machine access.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org