By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: CYCOGNITOPublished February 12, 2026

TL;DR: Traditional vulnerability KPIs such as open CVEs, patch rates, and backlog size measure activity rather than exposure, and CTEM should replace them with outcome-driven measures focused on validated issues, remediation effort, and continuous testing coverage, according to CYCOGNITO. The shift matters because leadership decisions improve only when reporting reflects attacker-relevant risk, not scan volume.


At a glance

What this is: This is an analysis of why conventional vulnerability metrics fail and how CTEM replaces them with exposure-focused KPIs.

Why it matters: It matters because IAM, NHI, and broader security programmes need metrics that reflect actual risk reduction, not just more activity or better scan coverage.

By the numbers:

  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read CYCOGNITO's analysis of CTEM metrics and exposure-focused security reporting


Context

Continuous Threat Exposure Management changes the question from how many findings exist to which exposures can actually be exploited. That matters because vulnerability counts, patch rates, and backlog size are easy to report but poor at describing whether an organisation is safer.

For identity and access programmes, the same reporting problem appears in NHI, secrets, and privileged access workflows. A programme can look active while still leaving exposed credentials, over-privileged accounts, or unmanaged third-party access untouched.

This article treats CTEM as a measurement reset rather than a tooling discussion, and that starting position is common in mature security programmes that have outgrown volume-based reporting.


Key questions

Q: How should security teams measure exposure instead of just counting vulnerabilities?

A: Security teams should measure whether issues are validated, reachable, and relevant to assets that matter, then report only the subset that can realistically change risk. That means combining exploitability evidence, asset criticality, and ownership so leadership sees decisions, not scan output. The goal is fewer false urgencies and clearer prioritisation.

Q: Why do vulnerability counts often fail to reflect actual risk?

A: Counts fail because they treat all findings as equal even when context is not equal. A vulnerability only becomes operational risk when it is exploitable, exposed, and connected to a system that matters. Without that context, teams can improve metrics while leaving the highest-risk paths untouched.

Q: What breaks when remediation metrics focus only on issues closed?

A: Teams can optimise for throughput while ignoring whether the closed issues mattered. That hides the operational cost of urgent escalations and rewards work that produces motion rather than risk reduction. A better signal is the time and capacity consumed by the issues that were truly urgent.

Q: How do you know if continuous testing is actually working?

A: You should see faster conversion from raw findings to confirmed risk, fewer disputed remediation priorities, and clearer evidence that validation is happening between assessment cycles. If the programme still relies on quarterly snapshots to tell you what is exploitable, it is not continuous in operational terms.


Technical breakdown

Why volume-based vulnerability metrics mislead leadership

Traditional vulnerability metrics are proxy measures, not risk measures. A rising count can mean better discovery, while a falling backlog can simply mean narrower scanning. Patch percentages also fail as a security indicator because they reward throughput without proving that an exploitable path has been removed. CTEM replaces this with exposure validation, which asks whether an issue is reachable, exploitable, and relevant to a critical asset. That distinction changes reporting from operational activity to decision quality.

Practical implication: replace headline CVE counts with validated exposure measures tied to business-critical assets.

How CTEM turns remediation into a prioritisation signal

CTEM treats remediation effort as a scarce operational resource, not a vanity metric. Counting closed issues hides the cost of escalations that pull engineers off planned work and can erode trust when too many alerts are low value. Measuring hours spent on urgent remediation reveals whether prioritisation is accurate or whether the programme is generating avoidable noise. This is especially useful when leadership needs to see the trade-off between speed and actual exposure reduction.

Practical implication: track remediation hours for urgent issues and use them to test whether prioritisation is reducing noise.

Why continuous testing coverage matters more than point-in-time testing

Annual tests and periodic assessments provide snapshots, but they do not sustain confidence between windows. Assets change, configuration drift accumulates, and new exposure paths appear without notice. CTEM reframes coverage as a service level against a defined critical asset set, which means an asset is either currently validated or it is not. This is a closer match to how attackers operate, because they exploit stale assumptions rather than annual test results.

Practical implication: define a testing cadence SLA for critical assets and treat missed cadence as a coverage failure.


NHI Mgmt Group analysis

CTEM exposes a deeper measurement problem, not just a tooling problem. Security programmes have long mistaken visible activity for reduced exposure. That error is especially costly in identity and NHI governance, where scans, reviews, and rotation tasks can all happen on schedule while the highest-risk credentials remain untouched. The discipline shifts when teams measure whether action changes the attacker’s path rather than whether work was completed.

Validated exposure should become the organising concept for executive reporting. The strongest contribution of CTEM is not another dashboard, but a tighter definition of what deserves attention. When validation includes reachability, exploitability, and asset criticality, leaders can stop funding noise and start funding decisions. That aligns naturally with NIST-CSF and with NIST SP 800-53 Rev 5 Security and Privacy Controls around access control, audit, and system integrity.

In identity programmes, this creates a metric gap around non-human access and secrets. NHI estates often look healthy in aggregate because inventory and rotation status are reported separately from business impact. A standing service account with broad reach can disappear inside a green status report if teams only count completed tasks. Practitioners should treat this as a governance failure in the measurement model itself, not a remediation backlog.

Continuous testing coverage is the named concept organisations should operationalise. The article’s logic points to a simple but demanding principle: if a critical asset is not under a current testing cadence, it is outside the validated risk envelope. That is a more disciplined way to run exposure management than periodic assurance, and it gives security teams a clearer basis for prioritisation, escalation, and board reporting.

What this signals

Validated exposure will become the metric that survives board scrutiny. CTEM does not replace operational telemetry, but it does demote vanity counts that cannot prove risk reduction. For identity-heavy programmes, that means reports should increasingly distinguish between inventory, validation, and material exposure. The programmes that do this well will spend less time defending numbers and more time demonstrating control.

Exposed identity paths remain the hardest thing for security teams to measure accurately. When credentials, service accounts, and third-party access are managed separately from exploitability and asset criticality, the reporting model breaks. Teams that want better exposure decisions should pair CTEM thinking with Ultimate Guide to NHIs , Key Challenges and Risks and the control expectations in NIST Cybersecurity Framework 2.0.

Continuous testing coverage is the operational bridge between identity governance and exposure management. If a workload, service account, or external asset is not under current validation, the organisation is assuming safety without proof. That is the same governance mistake whether the subject is vulnerability management or NHI oversight, and it is where prioritisation discipline has the most leverage.


For practitioners

  • Replace activity KPIs with exposure KPIs Retire top-line metrics that only count vulnerabilities, patch throughput, or backlog size. Build reporting around validated issues that are reachable, exploitable, and relevant to assets that matter to the business.
  • Measure urgent remediation effort directly Track engineering and operations hours spent on emergent remediation, not just the number of issues closed. Use that measure to identify where escalation volume is consuming capacity without reducing real exposure.
  • Define continuous testing SLAs for critical assets Set a testing cadence for each critical asset and treat any missed cadence as a coverage break. This is the clearest way to distinguish validated assets from assumed coverage.
  • Separate hygiene from decision-making Route unvalidated findings into normal hygiene processes instead of executive reporting. Keep leadership focused on the small set of issues that materially change exposure.

Key takeaways

  • CTEM reframes security reporting around validated exposure, not raw vulnerability volume.
  • Remediation effort and continuous testing coverage are stronger indicators of control than backlog or patch counts.
  • Identity and NHI programmes need reporting that separates hygiene from attacker-relevant risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0ID.IM-1CTEM aligns to improvement through validated exposure measurement and reporting.
NIST SP 800-53 Rev 5RA-5Vulnerability scanning is central, but CTEM adds validation beyond raw discovery.
CIS Controls v8CIS-7 , Continuous Vulnerability ManagementCTEM builds on continuous vulnerability management but narrows attention to actionable exposure.
MITRE ATT&CKTA0007 , Discovery; TA0040 , ImpactExposure validation helps separate benign findings from attacker-relevant paths to impact.

Map validated issues to attack paths that could plausibly lead to impact, not every detected finding.


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.
  • Exposure Validation: The process of confirming what data actually left the environment, where it came from, and how it could be abused. It is a post-incident governance step that links incident response, data classification, and identity risk assessment.
  • Testing Cadence SLA: A defined service-level expectation for how often a critical asset must be tested or revalidated. It turns security testing from periodic assurance into an ongoing control, making missed coverage visible as a governance failure rather than a scheduling issue.

What's in the full article

CYCOGNITO's full article covers the operational detail this post intentionally leaves for the source:

  • The full rationale for why volume-based KPIs fail executive reporting and how CTEM changes the decision model.
  • The article's breakdown of the three proposed KPIs and the exact way each one maps to exposure reduction.
  • The practical interpretation of what counts as a validated issue versus normal hygiene work.
  • The implementation framing for continuous testing coverage across a critical asset set.

👉 CYCOGNITO's full article explains how to move from vulnerability counts to outcome-driven exposure measurement.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity decisions to measurable security outcomes.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org