TL;DR: Cisco’s end-of-life for Kenna underscores a broader shift: security teams now face cloud misconfigurations, identity exposures, vendor risk, and app vulnerabilities in one expanding attack surface, according to Nucleus. The decisive challenge is no longer counting issues but operationalising continuous prioritisation and remediation across the full exposure graph.
At a glance
What this is: Nucleus frames Cisco’s Kenna end-of-life as a marker that vulnerability management alone no longer matches the modern attack surface.
Why it matters: IAM, cloud security, and DevSecOps teams need exposure management because identity exposures, misconfigurations, and dependencies now create risk that scanner-centric programs do not fully capture.
Context
Exposure management is the broader discipline of finding, correlating, and reducing risk across vulnerabilities, misconfigurations, identity exposures, third-party dependencies, and remediation workflows. The problem is not a lack of scan data, but a lack of operational control over which exposures matter most and who fixes them.
The article’s core governance point is that modern security programmes have outgrown spreadsheet-era vulnerability management. For teams that run IAM, PAM, cloud, AppSec, and vendor-risk processes separately, the gap is not only technical but organisational: exposures now move across domains faster than ownership and remediation paths do.
Key questions
Q: Which frameworks help teams move from vulnerability management to exposure management?
A: NIST CSF and NIST SP 800-53 help structure governance, while EPSS and CISA KEV inform exploitability. For application and dependency risk, CTEM-style processes work best when paired with runtime context, asset criticality, and automated ticket routing to engineering owners.
Q: Why do identity issues often change exposure prioritisation?
A: Identity issues matter because many attack paths depend on credentials, privilege, delegation, and trust relationships rather than a single technical flaw. If an exposure does not create a usable path through identity controls, it may be less urgent than a lower-rated issue that does. Prioritisation should therefore include access pathways, not only asset severity.
Q: What breaks when teams rely on scanner output alone?
A: Scanner-only programmes drown teams in duplicate, low-context alerts and push attention toward technical severity instead of exploitability. That creates alert fatigue, delays meaningful remediation, and leaves reachable exposures open while engineers chase dead ends. Validation and business context are what turn data into action.
Q: Why do stripped audit-log fields create so much risk for IAM and cloud security teams?
A: Because the field often carries the only unambiguous proof of what changed. If policyDelta is removed, a SetIamPolicy event can no longer be reliably interpreted as logging removal, a role grant, or a harmless update. That turns precise detections into guesses and makes silent coverage loss much more likely.
Technical breakdown
Why vulnerability scoring no longer matches exposure reality
Traditional vulnerability management assumes the primary task is to rank known CVEs by exploitability and severity. That model worked when the attack surface was mostly servers, scanners, and patch cycles. Exposure management expands the unit of analysis to include configuration drift, identity paths, vendor dependencies, and runtime context. The practical difference is that a high-scoring flaw may be less urgent than a lower-scoring issue sitting on an internet-facing asset with reachable credentials or weak controls. This is why prioritisation engines now need asset, identity, and threat context, not just scanner output.
Practical implication: Security teams should stop treating scanner severity as the decision engine and instead correlate exploitability with identity, asset, and business context.
How exposure management changes remediation orchestration
Exposure management is not just a better dashboard. It is an operational model that links discovery to action across security, IT, cloud, and engineering. In practice, that means continuously identifying exposures, mapping them to ownership, and pushing fixes into existing remediation workflows rather than leaving them as queued tickets. The article’s point is that measurement without closure simply preserves backlog. A real exposure platform must therefore support closed-loop remediation, otherwise prioritisation remains advisory instead of executable.
Practical implication: Build remediation routing that assigns each exposure to a clear owner, deadline, and workflow rather than a generic backlog item.
Why identity exposures now belong in exposure programs
Identity is now part of the exposure graph, not a separate governance lane. Service accounts, tokens, over-privileged roles, stale access paths, and third-party identities can create attack paths even when the underlying application or host is patched. That is why exposure management increasingly has to connect vulnerability data with access data and configuration state. For IAM and PAM teams, the issue is not only whether credentials exist, but whether those credentials create reachable risk in the current environment. In that sense, exposure management validates the need for stronger identity governance inside security operations.
Practical implication: Bring IAM and PAM signals into exposure prioritisation so identity paths are weighted alongside code and infrastructure findings.
Threat narrative
Attacker objective: The objective is to turn fragmented exposures into a usable path to access, privilege, and operational disruption.
- Entry begins when attackers choose the most reachable exposure, which may be a misconfiguration, vulnerable dependency, or identity path rather than a single software flaw.
- Escalation occurs when the exposure is combined with context such as weak privilege boundaries, exposed credentials, or unmanaged third-party access.
- Impact follows when multiple exposure types are chained together, allowing attackers to move from a single weakness to broader environment compromise.
Breaches seen in the wild
- Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.
- Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.
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 management is now the more accurate governance model for modern attack surface risk. Vulnerability management remains necessary, but it is no longer sufficient when cloud misconfigurations, identities, and vendor dependencies can matter more than raw CVSS volume. The strategic question has shifted from how many issues exist to which exposures can actually be reached and chained. Practitioners should treat exposure management as the control plane for prioritisation, not as a reporting layer.
Identity exposures are now first-class exposure objects, not edge cases. Service accounts, API keys, tokens, and over-privileged access paths can create compromise routes even when systems are otherwise patched. That means exposure management must consume identity signals from IAM and PAM, because the issue is often not defect count but reachable privilege. Practitioners should align access governance with exposure scoring so identity risk is visible in the same workflow as infrastructure risk.
The real operational failure in legacy vulnerability programmes is backlog preservation. Many teams can identify issues, but they cannot close the loop across ownership domains fast enough to change risk. This is where the market is moving toward a named concept: exposure closure latency, the time between discovery and verified remediation across security and engineering teams. Practitioners should measure that latency as a governance outcome, not just patch counts.
Platform thinking matters because exposure is cross-domain by nature. Separate tools for scanning, cloud posture, IAM, and ticketing cannot by themselves establish a system of record for exposure. The market is signalling that practitioners need a control model that unifies prioritisation, orchestration, and verification. Practitioners should evaluate whether their current stack can govern exposure end to end rather than merely enumerate it.
What this signals
Exposure closure latency: the new governance question is how quickly discovery turns into verified reduction of reachable risk. If a programme cannot move from finding to fixing across security, cloud, and identity teams, then it is cataloguing exposure rather than managing it.
The practical shift for readers is to align exposure workflows with ownership boundaries that already exist in IAM, PAM, DevOps, and infrastructure teams. That means prioritisation must be fed by identity reachability and configuration context, not only by scanner severity or backlog size.
For practitioners
- Prioritise exposures by reachable attack path Score issues using exploitability, internet exposure, identity reachability, and business context instead of severity alone.
- Integrate identity signals into exposure workflows Feed privileged accounts, service identities, tokens, and access paths into the same queue that handles infrastructure and application risk.
- Replace backlog metrics with closure metrics Track time from discovery to verified remediation so leadership can see whether prioritisation is actually reducing risk.
- Unify ownership across security and engineering Assign each exposure to a named fixing team with workflow handoff rules for cloud, appsec, IT, and IAM remediation.
Key takeaways
- Exposure management is replacing vulnerability management because modern attack surfaces now include identities, misconfigurations, dependencies, and vendor risk, not just CVEs.
- The central governance problem is no longer counting issues but closing the loop from discovery to remediation across multiple teams.
- Identity and cloud signals have to influence prioritisation if organisations want to reduce reachable risk instead of merely reporting it.
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 |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities | The article centers on prioritising and managing exposure across assets, not just individual CVEs. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity exposures are a core part of the expanded exposure graph discussed in the article. | |
| Recommendation — Use ID.RA-01 to tie exposure prioritisation to asset context and business impact, not scanner volume. Apply PR.AA-05 to ensure identity reachability is part of exposure scoring and remediation order. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Cloud misconfigurations are explicitly named as part of the modern exposure surface. |
| Recommendation — Use CIS-4 to reduce configuration-driven exposure before it becomes an operational attack path. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article’s exposure model includes identity paths that can support access and movement. |
| Recommendation — Map reachable identity exposures to TA0006 and TA0008 so prioritisation reflects likely attacker progression. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service identities and access paths are part of the exposure graph, especially where privilege expands reachability. |
| Recommendation — Review overprivileged NHI access so identity-driven exposure is reduced alongside software flaws. | ||
Key terms
- Exposure management: Exposure management is the practice of identifying which assets are reachable by attackers and reducing that reach before exploitation occurs. For collaboration systems like SharePoint, it is not enough to know that a patch exists, because public accessibility changes the speed and likelihood of attack.
- Exposure-to-Closure Latency: Exposure-to-closure latency is the time between identifying a security weakness and proving it has been fixed. It is a practical governance measure because it captures whether findings actually change risk, rather than simply increasing ticket volume or reporting output.
- Reachable risk: Reachable risk is a weakness that can be exercised in a live environment, not just detected in source code or configuration files. It is the practical threshold that separates low-value noise from issues that can lead to exploitation, data exposure, or service disruption.
- Closed-Loop Remediation: A governance process that does not stop at finding risk. It removes or reduces access, confirms the change in the source systems, and keeps evidence that the risky condition stayed fixed. For NHIs, this is the difference between inventory and actual risk reduction.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, helps practitioners understand NHI governance, machine identity security, secrets management, and the access controls that shape exposure risk. It is relevant for teams that need to connect identity governance with broader security operations and remediation workflows.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org