Not A Vulnerability (NAV)

What NAV Means in Security Triage

Not A Vulnerability is a triage outcome, not a technical finding. It tells reviewers that the reported behaviour does not meet the organisation’s threshold for an exploitable flaw, often because the behaviour is intended, accepted, or outside the product’s supported security boundary.

This label matters because it turns a raw report into a decision: the issue may still deserve documentation, customer communication, or a product clarification, but it should not be tracked or remediated as a vulnerability unless the underlying facts change.

Why NAV Exists in Vulnerability Management

NAV is used to keep vulnerability workflows accurate. Without a clear “not a vulnerability” outcome, teams can waste remediation effort on expected behaviour, duplicate reports, configuration choices, or requests that belong in product support rather than security engineering.

It also helps preserve signal quality in metrics. If every complaint is treated as a vulnerability, prioritisation, SLAs, and executive reporting become less reliable because the backlog mixes true weaknesses with non-issues.

How Teams Decide Whether a Report Is NAV

Teams usually test the report against their own vulnerability definition, the product’s documented design, and the system’s intended trust boundaries. A report can still be technically real and still be NAV if the behaviour is by design or if the reporter has not shown a security impact that changes confidentiality, integrity, or availability.

Good triage separates “unexpected” from “exploitable.” A surprising result, a risky configuration, or a hard-to-understand product choice is not automatically a vulnerability. The key question is whether an attacker can meaningfully abuse the condition to gain unauthorized effect, data access, privilege, or disruption.

NAV in Triage and Disclosure Workflows

Well-run programmes treat NAV as part of the disclosure lifecycle, with a clear explanation to the reporter and a record of why the issue was closed that way. That helps maintain consistency across analysts, support teams, and security reviewers, especially when similar reports recur over time.

When a report is marked NAV, the decision should be anchored in the product’s actual behaviour and scope statement, not in convenience or assumption. If the same condition later becomes exploitable through a different code path, dependency, or environment, the classification must be revisited.

Risk and Threat Considerations

NAV can be misapplied if teams use it to dismiss a real weakness too quickly. The main risk is false closure: a genuine security issue may be hidden behind an incomplete reproduction, an unclear threat model, or a narrow reading of scope.

Failure mechanism: The report is closed as expected behaviour even though an attacker can combine that behaviour with another weakness, a misconfiguration, or a trust assumption to create a real exploit path.

Impact: The organisation may miss a fixable exposure, leave customers unprotected, or accumulate repeated disclosures that should have been converted into product changes rather than closed as non-issues.

Practitioner Guidance

What to watch for: Use NAV only when the evidence clearly shows the behaviour is intended or not security-relevant under the organisation’s definition. If the report is ambiguous, document the exact decision criteria, the scope assumption, and what would cause the classification to change.

Governance implication: NAV decisions should be auditable and repeatable, because they affect both reporter trust and vulnerability programme quality. A consistent standard for when something is “not a vulnerability” is just as important as the standard for accepting a finding.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• Why does AI-driven vulnerability discovery change NHI governance?
• What is the difference between vulnerability scanning and continuous exposure management?
• What is the difference between theoretical vulnerability and reachable risk?