TL;DR: Vulnerability management is producing more scanner noise than security value, while CTEM shifts prioritisation toward reachability, exploitability, and business risk, according to ArmorCode's analysis. The practical break point is no longer CVSS volume but whether exposures sit on real attack paths that attackers can use.
At a glance
What this is: This is an analysis of why vulnerability management is losing effectiveness in 2026 and how CTEM changes prioritisation from CVSS noise to attack-path risk.
Why it matters: IAM, NHI, and security teams should care because CTEM surfaces how identity exposures, weak permissions, and reachable misconfigurations create risk that scanner queues alone do not govern.
Context
Vulnerability management is designed to find software flaws, but it breaks down when environments change faster than ticket queues can absorb the findings. In hybrid cloud, ephemeral container, third-party API, and identity-heavy estates, the real problem is not discovery alone but deciding which exposures are actually reachable and consequential.
CTEM reframes that governance gap. Instead of asking how many vulnerabilities exist, it asks which exposures attackers can chain into an attack path, including misconfigurations, identity exposure, cloud posture gaps, and supply chain weaknesses. That makes the article relevant to IAM and NHI governance as well as broader security operations, because access scope and reachability now drive remediation priority.
Key questions
Q: What breaks when organisations rely only on traditional vulnerability assessments instead of CTEM?
A: Traditional assessments often identify issues without keeping pace with changing attack paths, so remediation priorities can drift from current reality. The main breakdown is visibility gaps between tests, which means teams may believe they are protected while new exposures emerge. CTEM addresses that weakness by making validation ongoing, so security work tracks live conditions rather than old findings.
Q: Why do reachability and business criticality matter more than CVSS alone?
A: CVSS describes technical severity, but it does not tell you whether the issue is reachable, connected to a crown jewel, or combined with other weaknesses that make it exploitable. Reachability and business criticality turn raw findings into operational risk decisions, which is what exposure governance actually needs.
Q: How do security teams know if an exposure programme is actually working?
A: Look for fewer verified attack paths, not just fewer alerts. A working programme produces evidence that exploitable paths are being removed, high-risk assets are being remediated first, and false positives are falling over time. If dashboards improve but attack paths remain, the programme is only reporting better.
Q: What should teams do when identity exposures appear in vulnerability workflows?
A: They should treat identity findings as part of the same exposure lifecycle, not as a separate backlog. Weak permissions, exposed secrets, and overbroad access can be the path that turns a technical flaw into a compromise, so identity context must influence prioritisation and ownership from the start.
Technical breakdown
Why CVSS-driven queues fail in modern environments
Traditional vulnerability management treats each finding as an isolated item ranked by technical severity. CVSS helps compare flaws, but it does not express whether the asset is reachable, whether the exposure sits behind compensating controls, or whether the vulnerable component has any realistic path to business impact. In practice, that creates queues full of urgent-looking items with very different real-world risk. The result is not just inefficiency. It is a governance failure where the control system measures flaw volume more accurately than exposure significance.
Practical implication: move prioritisation away from score-only queues and toward validated reachability and business context.
How CTEM changes exposure management from scanning to validation
CTEM is built around continuous exposure assessment rather than point-in-time scanning. The important shift is that a finding only matters after it is validated in the live environment and shown to be reachable and exploitable. That removes inherited trust in scanner output and forces security teams to distinguish between theoretical weakness and operationally relevant exposure. This is especially important in estates where cloud, identity, and application layers interact, because the attack path often depends on configuration and privilege relationships rather than the CVE alone.
Practical implication: validate exposures against the live attack surface before sending them into remediation workflows.
Why identity and cloud posture now shape exposure risk
The article’s central point is that modern attackers do not need to stop at software vulnerabilities. They chain weak permissions, exposed secrets, misconfigurations, and third-party paths into a usable route to impact. That means identity posture and cloud posture are no longer side concerns inside vulnerability management. They are part of the exposure itself. When an attacker can reach a resource through overly broad access or an exposed control plane, the true issue is not the CVE title but the attack path enabled by governance gaps.
Practical implication: treat identity exposure, cloud posture, and access scope as first-class prioritisation inputs alongside software flaws.
NHI Mgmt Group analysis
CTEM succeeds where vulnerability management fails because it replaces volume with attack-path governance. Legacy VM programs optimise for finding more issues, not for deciding which issues matter. That distinction is now decisive because attackers exploit reachability and exposure chains, not scanner queues. Practitioners should treat prioritisation logic as a control surface, not an operational convenience.
The real governance gap is the assumption that technical severity equals business risk. CVSS can describe a flaw, but it cannot tell you whether the asset is reachable, whether compensating controls exist, or whether identity pathways make the exposure usable. This is why many teams keep remediating dead ends while leaving true attack paths open. Practitioners need a prioritisation model that reflects operational exposure, not inherited score.
Attack-path visibility is now the named concept that security leaders need to govern. The article shows that dead-end findings and exploitable findings look similar inside legacy workflows until contextual analysis separates them. That makes attack-path visibility a management requirement, not a reporting feature. Practitioners should align security operations around validated exposure, because that is the boundary between noise and risk.
Identity exposure must be folded into exposure management, not tracked as a separate exception list. The article explicitly notes that attackers chain weak permissions, exposed secrets, and misconfigurations. That means IAM and NHI teams cannot sit outside CTEM and wait for separate remediation queues. Practitioners should govern identity reachability as part of the same exposure lifecycle as infrastructure and application flaws.
CTEM is becoming the more realistic operating model for hybrid environments because the environment now moves faster than patch cadence. Weekly or monthly VM cycles cannot keep pace with ephemeral infrastructure, third-party dependencies, and rapidly changing privileges. The important shift is not tool consolidation but decision velocity. Practitioners should evaluate whether their current VM process can still support timely business decisions under continuous change.
What this signals
Attack-path visibility: the useful unit of work is no longer the raw vulnerability count, but the subset of exposures that an attacker can actually reach and chain into impact. For practitioners, that means shifting from periodic patch hygiene to continuous exposure governance across cloud, identity, and application layers.
The strongest CTEM programmes will be the ones that collapse scanner output, cloud posture, and identity context into one decision layer. That is where remediation becomes defensible, because teams can explain why one finding moves first and another waits.
For IAM and NHI teams, the message is straightforward: access scope is now part of exposure management. If permissions, secrets, or delegated paths make a weakness reachable, the issue is no longer just technical vulnerability management but governance of who or what can use it.
For practitioners
- Prioritise attack-path validation over scanner severity Re-rank remediation queues using reachability, exploitability, and business context so CVSS does not automatically drive urgency. The objective is to send only reachable exposures into owner workflows.
- Consolidate findings into one exposure view Normalize scanner, cloud posture, application, and identity findings in a single control plane to eliminate duplicate alerts and the reconciliation tax. This reduces manual triage and makes prioritization defensible.
- Treat identity exposure as part of CTEM scope Include weak permissions, exposed secrets, and overbroad access paths in exposure review so identity risk is ranked alongside software flaws. Attackers often need both a vulnerability and a usable access path.
- Validate critical findings before ticketing Require live-environment validation for exposures that appear urgent so dead-end findings do not consume engineering time. Validation should confirm that the issue is actually reachable and exploitable in context.
- Route remediation by asset ownership and impact Replace scanner-originated ticket routing with workflows that attach validated risk, asset criticality, and owner context. That shortens the handoff from detection to closure and prevents generic patch queues.
Key takeaways
- Legacy vulnerability management struggles because it ranks technical severity higher than real exploitability, which leaves teams busy without reducing meaningful risk.
- CTEM shifts the unit of analysis from individual CVEs to validated exposure on real attack paths, making prioritisation more defensible.
- Identity posture, cloud posture, and software flaws now intersect inside the same exposure lifecycle, so remediation ownership must reflect reachability as well as severity.
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 API Security 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 | TA0007; TA0006; TA0008 — Discovery; Credential Access; Lateral Movement | The article centers on attack paths, exploitable exposure, and identity-driven chaining. |
| Recommendation — Map reachable exposures to ATT&CK tactics so prioritisation reflects how attackers move, not just what scanners find. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Identified | CTEM is about identifying and validating exposure in context rather than counting findings. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity exposures and weak permissions are part of the article's attack-path logic. | |
| Recommendation — Use ID.RA-01 to tie vulnerability discovery to risk-based validation and prioritisation. Apply PR.AA-05 to govern access scope as part of exposure management, not as a separate backlog. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article repeatedly points to weak permissions and identity exposure as exploitable conditions. |
| Recommendation — Audit account and entitlement sprawl so access paths do not turn low-severity issues into reachable exposures. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Third-party APIs and misconfigurations are part of the exposure model discussed in the article. |
| Recommendation — Inventory and harden API configurations so misconfiguration does not create a reachable attack path. | ||
Key terms
- Continuous Threat Exposure Management: Continuous Threat Exposure Management is the ongoing process of finding which assets, identities, and paths are actually reachable from the current environment. It moves risk assessment away from static inventories and toward live exposure, so security teams can prioritise what an attacker or misuse path can reach now.
- Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Reconciliation Tax: The manual effort required to combine duplicate alerts, normalise severity, and make sense of overlapping scanner outputs. It consumes analyst time, slows remediation, and often hides the small set of exposures that matter most.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a practical fit for security leaders who need to connect identity control decisions to broader programme risk.
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