TL;DR: Enterprise application attack rates rose from 55% in 2022 to 87% in 2026, while first hostile contact now occurs just 1 hour and 56 minutes after app store publication, according to Arxan Technologies. AI has compressed reverse-engineering and attack preparation enough that defenders must treat application exposure as an immediate runtime governance problem, not a post-release concern.
At a glance
What this is: Application attack rates have climbed sharply, with Arxan Technologies reporting 87% of enterprise applications attacked in 2026 and first hostile contact within 1 hour and 56 minutes of publication.
Why it matters: Appsec teams, IAM leads, and cloud security teams need to treat application release as the start of a live attack window, not the end of a build-and-publish process.
By the numbers:
- Since 2022, the attack rate on enterprise applications has risen from 55% to 87%.
- In 2026, connected-vehicle apps are attacked at the same rate as banking apps, at 91% each.
- The medical device vertical saw its largest single-year jump in attack rates, from 78% to 86%.
Context
Application attack rates are rising because AI has lowered the cost and time required to reverse-engineer software and prepare attacks. The article frames this as a shift from occasional exploitation to continuous exposure, where publication itself becomes the trigger for hostile attention.
That creates a governance problem for application security, but it also intersects with identity because apps increasingly carry embedded secrets, tokens, and delegated access paths. When those credentials are protected only by release-stage controls, the attack surface becomes operational immediately after deployment.
Key questions
Q: What breaks when application security assumes release-time review is enough?
A: Release-time review breaks when attackers can inspect, reverse-engineer, and probe a new app within minutes of publication. The practical failure is that secrets, API paths, and trust assumptions remain live long after the build is approved. Security teams need continuous runtime controls because publication is now the start of exposure, not the end of validation.
Q: Why do AI-assisted attacks increase application risk so quickly?
A: AI-assisted tooling reduces the effort required to find exposed endpoints, vary payloads, and test credentials at scale. That means the same weakness can be exploited faster and more repeatedly, even if the underlying vulnerability is familiar. Teams should assume that attack volume and speed will rise before their detection and response processes are fully adapted.
Q: How do security teams know if business application controls are working?
A: Look for three signals: fewer standing exceptions, cleaner SoD outcomes after role combination tests, and access review results that consistently remove unused permissions. If the same people keep receiving broad access across projects or system changes, the control model is drifting. Effective governance should narrow access over time, not accumulate it.
Q: Should organisations prioritise embedded secret removal over more app hardening?
A: They should prioritise both, but embedded secret removal usually comes first because exposed credentials collapse other controls. Hardening helps only if the application’s tokens, keys, and delegated access paths are not already extractable from the package or runtime environment. When secrets are present, attackers can bypass many other safeguards.
Technical breakdown
Why AI shortens the attacker preparation cycle
The article describes a compressed attacker workflow: less time, less skill, and fewer tools are now needed to analyse an app after release. In practice, LLM-assisted reverse engineering reduces the cost of finding exposed logic, hardcoded secrets, weak API flows, and trust boundaries that were previously harder to exploit. That does not mean every attack is automated, but it does mean the economics of discovery have changed. Defenders should assume that release artefacts, binaries, and mobile packages can be analysed almost immediately after publication, which shortens the safe window for relying on obscurity or post-release review.
Practical implication: Treat release artefacts as immediately exposed and remove security assumptions that depend on delayed attacker analysis.
Why runtime exposure now matters more than build-time assurance
Build-time controls still matter, but the report argues they are no longer enough on their own because hostile contact begins almost immediately. Application security now needs runtime governance that can detect abuse after publication, not just verify code before release. This includes secret hygiene, API hardening, tamper resistance, telemetry, and revocation paths for anything the app embeds or invokes. The core problem is temporal: the app exists in a hostile environment from the moment it becomes available, so controls that activate only after a change window or manual review are structurally late.
Practical implication: Shift control ownership from release approvals alone to continuous runtime monitoring and response.
What the 87% attack rate says about app trust boundaries
An attack rate of 87% signals that applications are operating inside a hostile baseline, not a low-frequency threat model. Once most apps are targets, trust assumptions about platform, geography, or vertical cease to be reliable predictors of safety. The article’s cross-vertical data, including banking, connected vehicles, and medical devices, shows that attackers follow opportunity and economics rather than sector boundaries. For practitioners, the important architectural question is not whether an app will be targeted, but which embedded credentials, API paths, and privileged integrations will be reachable when it is.
Practical implication: Revalidate trust boundaries, embedded credentials, and privileged integrations as if targeting is the default state.
Threat narrative
Attacker objective: The attacker aims to obtain practical leverage over the application, such as exposed credentials, abused API paths, or reliable exploit logic that can be reused at scale.
- Entry begins at app publication, where newly released code, binaries, or store packages become the first point of attacker inspection.
- Credential access and reverse engineering then expose secrets, API calls, or logic flaws that can be reused to authenticate, automate, or tamper with the app.
- Impact follows quickly because the attacker can exploit the exposed paths before defenders have time to detect, rotate, or harden the release.
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
Application exposure is now a runtime governance problem, not a release problem: once hostile contact arrives within minutes of publication, security teams can no longer treat pre-release assurance as the primary control plane. The report shows that attacker economics have shifted faster than many delivery pipelines. Practitioners need to govern exposure continuously from publication onward, not assume the build stage buys safety.
AI has created an attacker acceleration curve that mirrors the software delivery acceleration curve: the same technologies used to ship faster also help adversaries analyse faster. That changes the control objective from perfect prevention to faster detection, tighter containment, and narrower blast radius. For appsec and IAM teams, the important question is which embedded identities, tokens, and privileged integrations remain usable after release.
Immediate exposure window: the most important failure mode is the assumption that a newly published app has a grace period before serious abuse begins. This article shows that grace period has effectively collapsed. Teams should treat publication, especially mobile and connected-device publication, as the start of active defense, with control coverage extending into secrets, APIs, and runtime telemetry.
Sector boundaries are no longer a reliable risk shield: the convergence of attack rates across banking, connected vehicles, and medical devices shows that adversaries are following access opportunity, not industry labels. That weakens vertical-specific comfort and strengthens common control requirements across software estates. Practitioners should build security baselines around exposure mechanics, not around business sector assumptions.
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: Shadow AI and AI Agent Discovery Guide
What this signals
Immediate exposure windows are now the defining appsec problem: if hostile contact follows publication by minutes rather than days, then security teams have to govern software as a live service from the outset. The consequence is broader than mobile hardening alone, because the same exposure logic now applies to APIs, embedded secrets, and delegated credentials across the application estate.
Application attack economics now resemble secrets-sprawl economics: Arxan Technologies' figures show attackers no longer need a long preparation cycle to find leverage, which makes runtime containment and fast revocation more valuable than relying on obscurity or delayed review. According to the State of Secrets Sprawl 2026, AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
For practitioners
- Harden publication as a security event Treat app store release, package publishing, and update rollout as the start of an active attack window. Tie release approval to checks for embedded secrets, exposed endpoints, and privileged callbacks that would be exploitable in the first hour.
- Move runtime telemetry ahead of manual review Instrument applications so hostile probing, tampering, and anomalous API use are visible immediately after publication. Alerting should not wait for a scheduled review cycle, because the article shows hostile contact can arrive almost immediately.
- Inventory and revoke embedded credentials Identify tokens, API keys, certificates, and delegated access paths that ship with the application or are invoked on first run. Rotate or revoke anything that could survive reverse engineering or package extraction.
- Reassess mobile and connected-device trust assumptions Compare your mobile, vehicle, and device app controls against the threat conditions described here, especially where distribution happens outside traditional enterprise change control. The attack rate convergence across verticals suggests the same defensive baseline now applies across several product classes.
Key takeaways
- Application attack risk is no longer a niche or deferred concern, because hostile contact can begin almost as soon as software is published.
- AI has compressed the attacker workflow enough that reverse engineering and exploit preparation are now routine, low-friction activities.
- The control shift is from release-only assurance to continuous runtime governance over secrets, APIs, telemetry, and revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006;TA0007;TA0008;TA0010 — Credential Access; Discovery; Lateral Movement; Exfiltration | The article describes rapid reverse engineering, discovery, and reuse of exposed app logic and credentials. |
| Recommendation — Map post-publication abuse paths to ATT&CK and monitor for credential discovery, reuse, and lateral movement after release. | ||
| CIS Controls v8 | CIS-5 — Account Management | The report highlights exposed tokens and privileged access paths that need lifecycle control. |
| Recommendation — Apply account management discipline to embedded tokens, service accounts, and delegated access paths shipped in apps. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on privileged integrations and app access paths that become risky immediately after publication. |
| Recommendation — Review application entitlements and authorizations at release time and continuously after deployment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secrets, API keys, and certificates in published apps require lifecycle management and revocation. |
| Recommendation — Rotate and revoke embedded authenticators before publication and whenever exposure is suspected. | ||
Key terms
- Runtime Application Governance: Runtime application governance is the set of controls that watch, constrain, and respond to software while it is live in production. It focuses on exposure, abuse, and revocation after release rather than only on pre-deployment checks.
- Attacker Preparation Cycle: The attacker preparation cycle is the time and effort required to analyse software before exploitation begins. AI shortens this cycle by making reverse engineering, pattern extraction, and exploit planning faster and cheaper.
- Embedded Credential: A credential embedded in software, firmware, or automation that can be reused outside its intended context. In practice, it becomes a silent trust bridge between systems. For agents and connected devices, the risk is not the secret alone but the reach it grants if runtime controls are weak.
- Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect application exposure to the identity controls that determine whether embedded credentials can be abused.
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