CVSS v4.0 environmental metrics let you adjust a vulnerability's score for your own systems. You set how much confidentiality, integrity and availability matter for the affected asset, and you can override base metrics where your setup differs. The result reflects your environment instead of a worst case.
Where environmental metrics sit
CVSS v4.0 has four metric groups: Base, Threat, Environmental and Supplemental. The specification describes the Base group as intrinsic qualities that are constant over time and across environments. The Threat group covers characteristics that change over time, such as exploit maturity. The Environmental group covers characteristics relevant and unique to a particular consumer's environment. Supplemental metrics add context and do not change the score.
The specification also states that Threat and Environmental information is available only to the end consumer. A vendor publishes a base score. Only you know how the product is deployed.
The two kinds of environmental metric
| Kind | Metrics | What you tell CVSS |
|---|---|---|
| Security Requirements | Confidentiality (CR), Integrity (IR), Availability (AR) | How much loss of each property would hurt this asset |
| Modified Base | Modified Attack Vector, Attack Complexity, Attack Requirements, Privileges Required, User Interaction, and the impact metrics | Where your deployment differs from the published base values |
Each Security Requirement takes High, Medium, Low or Not Defined. The specification says Not Defined is the default and has the same effect as High.
A worked example in words
Say a vulnerability has a network attack vector in its base metrics. In your deployment, the vulnerable component listens only on a local interface. You can set Modified Attack Vector to Local, and the score is calculated as though the base attack vector were Local. The specification gives this behavior directly: if you set a modified metric, the score is calculated as if the base metric had that value.
Now say the affected system is a development sandbox with fake data. You can set Confidentiality Requirement to Low. The score drops, which is the point: the same flaw matters less there.
Steps to adopt this without a research project
- Pick one asset class, such as public web services.
- Set Security Requirements per asset from your data and criticality labels.
- Only use Modified Base metrics when you can prove the difference, for example a verified bind address.
- Record the vector string so others can see what you changed.
- Compare the adjusted score with the base score and look at the largest gaps.
Using the vector string matters. A bare number says nothing about how it was reached, while the string lists each metric.
Cautions
- Lowering a score based on an assumption is the same mistake as ignoring the flaw. Only modify what you can verify.
- Scores do not replace exploit evidence. A flaw on the CISA Known Exploited Vulnerabilities Catalog deserves attention even if an adjusted score looks modest.
- Not Defined means worst case, so leaving requirements blank will not understate risk. That is a safe default, but also a reason your scores will look high until you fill them in.
- Do not average scores across assets. Prioritize per asset.
Using the output
The environmental score is a better sort key than the base score for a single asset. It is still one input. Pair it with reachability and ownership before you decide a deadline.
Quick check
Who should set environmental metrics?
The team that owns the asset, reviewed by security. Vendors cannot know your deployment.
Do environmental metrics change the base score?
No. They produce a separate adjusted result. The base score stays as published.
Sources
Last reviewed: 19 October 2026.
