TL;DR: 60% of organisations had at least one exposed HTTP panel, and remediation in midmarket firms peaked at 56 days, leaving internet-facing assets exposed long enough to be discovered and abused, according to Intruder’s 2026 Attack Surface Management Index based on 3,000 attack surfaces. Patching alone is insufficient when exposure is the real root cause, and identity, access, and service hardening must move earlier in the control chain.
At a glance
What this is: This analysis says organisations are still leaving internet-facing panels, services, databases, and documents exposed, and patching alone does not remove the attack path if the asset should not be reachable at all.
Why it matters: For IAM, NHI, and security teams, the practical issue is that exposed systems turn passwords, tokens, service accounts, and admin access into easy entry points before vulnerability management can help.
By the numbers:
- 60% of organisations had at least one HTTP panel exposed.
- 49% exposed a risky port or service.
- 42% had an exposed database.
- 30% had files or information publicly accessible that shouldn't be.
Context
Attack surface exposure is the condition that creates the breach path before any vulnerability is exploited. When an admin panel, database, or service is internet-facing without a business reason, the organisation has already accepted unnecessary risk, because attackers do not need to break a control if the control was never meant to be exposed.
The identity connection is direct when exposed services rely on reused passwords, static API keys, or admin credentials. In those cases, access control and exposure control fail together, which means IAM, PAM, and NHI governance have to start earlier than patch cycles and config clean-up. This is a governance problem, not just a vulnerability problem.
Intruder’s findings are typical of a broader pattern in midmarket environments, where asset growth outpaces the teams responsible for discovery, hardening, and removal of stale access paths.
Key questions
Q: What breaks when an internal service is exposed to the internet by mistake?
A: The main failure is that the asset boundary disappears, so attackers can probe authentication, brute-force weak credentials, or exploit any flaw without first defeating perimeter controls. Exposed services also expand the blast radius of reused passwords, service accounts, API keys, and admin interfaces. Security teams should treat unwanted exposure as a control failure in its own right, not just as a hosting misconfiguration.
Q: Why do exposed systems remain risky even after the patch is installed?
A: Because attackers may already have established persistence before remediation completed. A patch can remove the vulnerable path while leaving malicious artefacts, backdoors, or privileged access intact. Security teams should assume remediation and eviction are separate tasks whenever a system was internet-facing during exploitation.
Q: What are the signs that manufacturing attack surface management is failing?
A: Common warning signs include unknown internet-facing assets, delayed remediation of exposed vulnerabilities, inconsistent inventory records across teams, and weak visibility into third-party exposures. If security teams cannot quickly identify what is exposed, which systems matter most, or whether remediation has actually reduced risk, the programme is not providing actionable control. Effective attack surface management should shrink uncertainty, not just generate more findings.
Q: When should organisations prioritise exposure management over traditional vulnerability management?
A: Organisations should prioritise exposure management when the main concern is what attackers can reach from outside, not just what is technically vulnerable inside the estate. It becomes especially important for public-facing services, exposed databases, remote access paths, and fast-changing cloud environments. Exposure management helps teams focus resources on the assets most likely to be attacked successfully.
Technical breakdown
Why exposed admin panels become the first control failure
An exposed HTTP or admin panel is not a vulnerability in the narrow CVE sense, but it often becomes the first operational failure because it moves an internal control surface onto the public internet. Once that happens, the organisation is relying on authentication strength, rate limiting, and monitoring to defend an asset that should never have been reachable externally. Password reuse, guessed credentials, and social engineering all become easier when the login surface is public. For IAM and NHI governance, the issue is that identity controls cannot compensate for an unnecessary exposure path.
Practical implication: Prune external reachability first, then treat authentication hardening as secondary protection rather than the primary fix.
How exposed databases and services turn secrets into attack paths
Public databases and legacy services are high-value because they often contain or depend on reusable secrets, service credentials, and remote administration paths. If attackers can reach them directly, they can target the weakest adjacent control, whether that is a weak password, a token in memory, or a management interface left open for convenience. The article’s MongoBleed example is a useful reminder that exposure can turn a software flaw into direct credential theft. This is where NHI risk appears: service accounts, API keys, and session tokens become reachable because the service boundary was never enforced.
Practical implication: Inventory externally reachable assets and remove any path that exposes secrets, tokens, or administrative functions to unauthorised networks.
Why patching slows down once exposure becomes the bottleneck
Patch-first models assume the main problem is remediation speed after a flaw is known. Attack surface exposure changes that assumption because the security team may still be exposed long before a patch is available, approved, or deployed. If a service is reachable from the internet, time-to-exploit collapses from a patching problem into a discovery problem. That is why attack surface management and vulnerability management need to be linked but not confused: one reduces reachable exposure, the other reduces exploitable weakness.
Practical implication: Use exposure reduction as the front-line control and patching as the follow-on control for what remains reachable.
Threat narrative
Attacker objective: The attacker wants a public foothold that bypasses defensive depth and yields credentials, data, or privileged access with minimal effort.
- Entry begins with an internet-facing admin panel, database, or service that was never meant to be publicly reachable.
- Credential access follows when attackers guess reused passwords, brute-force weak credentials, or exploit a flaw that exposes secrets and session material.
- Impact occurs when exposed assets are abused to steal data, obtain administrative access, or pivot into the wider environment.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
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
Exposure control is now a governance control, not just an operations task. The article shows that the core failure is not simply whether a system is patched, but whether it should have been internet-facing at all. That changes the decision boundary for IAM, PAM, and NHI teams because reachability determines how much identity and credential risk exists before an attacker even starts. Practitioners should treat exposure removal as a first-class control objective.
Patch velocity is not a substitute for attack surface reduction. When remediation takes weeks, the security value of a patch-first model depends on the asset being discoverable and exploitable in the first place. If an exposed service is already public, the clock starts at exposure, not disclosure. The operating lesson is that teams need a policy for removing unnecessary public access before they rely on remediation speed.
Service accounts and static secrets become more dangerous when the surrounding service is exposed. Exposed infrastructure does not merely increase generic risk; it expands the reach of credential compromise, especially where admin interfaces, APIs, or databases depend on reusable machine credentials. This is where NHI governance intersects with attack surface management in a practical way: inventory and reachability are part of the identity problem, not separate from it.
Midmarket organisations face a detection and removal gap that attackers can exploit. The article’s remediation timing suggests that scale creates operational drag faster than teams can absorb it. That drag is what turns exposure into a durable risk, because the public surface stays open while attention moves elsewhere. Practitioners should align ownership for discovery, hardening, and access review so that exposure does not linger between teams.
Attack surface management is the named concept that captures the real problem here. It is the discipline of finding what is reachable, deciding what should not be reachable, and removing those paths before vulnerability response becomes necessary. For security programmes, the implication is clear: if the asset boundary is wrong, the best patch process in the world is still working too late.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Attack surface exposure is a governance problem because the organisation is deciding, often implicitly, which systems the internet can reach. When that decision is left to legacy settings or convenience, identity controls inherit too much risk from the start. Exposure governance should sit alongside IAM and PAM because public reachability changes the cost of every credential failure.
Machine credentials become more brittle when they are attached to public-facing services. The 113,000 new exposed API keys attributed to DeepSeek alone in 2025 is a reminder that new platforms create credential exposure faster than control owners can absorb it, according to the State of Secrets Sprawl 2026. That pattern matters because exposed infrastructure and exposed secrets reinforce each other.
Attack surface management and NHI governance now overlap in the same failure mode: public reachability plus reusable secrets. If service accounts, API keys, or admin credentials can be used on a service that should not be public, the issue is not just vulnerability management. Practitioners should move exposure review earlier in the change process and treat reachability as an identity risk signal.
For practitioners
- Tighten internet exposure policy Classify every externally reachable panel, database, and service by business necessity, then remove public access for anything that does not have an explicit external use case.
- Bind IAM review to exposure review Require access owners to validate whether exposed assets depend on static passwords, API keys, or admin logins, and retire any access path that exists only for convenience.
- Prioritise removal over patching When a new flaw appears on a public service, first confirm whether the service should be internet-facing at all, then patch only the assets that still need exposure.
- Track exposed asset dwell time Measure how long panels, services, and databases remain publicly reachable after discovery, and use that metric to drive ownership and remediation escalation.
- Harden machine credentials on exposed systems Rotate or revoke service credentials and API keys attached to public-facing infrastructure, especially where logs, memory, or admin tooling could expose them.
Key takeaways
- The core risk is not only exploitable software, but exposed services and panels that should never have been internet-facing in the first place.
- The article shows that 60% of organisations still had at least one exposed HTTP panel, and some midmarket remediation cycles stretched to 56 days.
- Security teams should remove unnecessary public reachability before they rely on patching, because exposure turns ordinary credentials and flaws into immediate attack paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0006;TA0040 — Initial Access; Credential Access; Impact | Public exposure enables direct entry, credential abuse, and downstream impact. |
| Recommendation — Map public-facing exposure to TA0001, TA0006, and TA0040 to prioritise removal and monitoring. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Unnecessary external reachability reflects broken access-authorisation boundaries. |
| Recommendation — Apply PR.AA-05 to ensure only justified systems remain externally reachable. | ||
| CIS Controls v8 | CIS-5 — Account Management | Exposed admin surfaces increase the impact of weak account and credential governance. |
| Recommendation — Use CIS-5 to remove unnecessary accounts and access paths on internet-facing systems. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Public exposure of services and panels often exposes API keys, tokens, and other machine secrets. |
| NHI-05 — Overprivileged NHI | Exposed services often carry machine credentials with more privilege than the asset needs. | |
| NHI-07 — Long-Lived Secrets | Long-lived API keys make public exposure more durable and more exploitable. | |
| Recommendation — Use NHI-02 to find and revoke secrets attached to exposed services and panels. Use NHI-05 to reduce privilege on service accounts tied to public-facing infrastructure. Use NHI-07 to replace long-lived keys on exposed systems with shorter-lived credentials. | ||
Key terms
- Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
- Exposed HTTP Panel: An exposed HTTP panel is a web-based administrative interface that is reachable from the internet. These panels often belong to infrastructure or application tools and can become high risk when they are forgotten, weakly protected, or left online without a clear business need or owner.
- Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.
- Internet-Facing Asset: An internet-facing asset is any system, service, or resource reachable from the public internet. That can include production hosts, cloud storage, APIs, staging systems, and remote consoles. These assets matter because attackers can enumerate and test them without internal access, making misconfigurations and forgotten services immediate security concerns.
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 identity controls to the wider security programme they operate every day.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org