CVSS 4.0 split the old Attack Complexity metric in two. Attack Complexity now covers built-in defenses the attacker must evade, or secrets they must obtain. Attack Requirements covers external conditions of the target that must line up, such as a race or an on-path position. One is about defenses, the other about circumstances.
The short rule
The FAQ gives the clearest summary:
- Attack Complexity (AC) is about built-in challenges. The attacker must actively evade or circumvent security-enhancing conditions, or gather a target-specific secret that cannot be found by reconnaissance alone.
- Attack Requirements (AT) is about external challenges. Deployment and execution conditions of the vulnerable system must be overcome.
Why "AT" and not "AR"? Because AR already means Availability Requirements, and the specification does not allow two metrics to share an abbreviation.
Examples from the documents
For Attack Complexity, the specification lists evading exploit mitigations such as address space randomization (ASLR) or data execution prevention (DEP). It also lists obtaining a target-specific secret, for example a key needed to break an encrypted channel.
For Attack Requirements, the FAQ names race conditions and on-path network injection, sometimes called machine in the middle.
A quick test: if the attacker has to beat a protection, think AC. If the attacker needs the situation to be right, think AT.
A frequent mistake
Do not use Attack Requirements to record an unusual configuration that makes the system vulnerable in the first place. The FAQ is firm on this. The words about conditions of the vulnerable system refer only to challenges the attacker faces, not to settings that put the system into a vulnerable state.
The assessor should assume the vulnerable configuration. If a flaw only exists when a rarely used option is on, score it as if the option is on, and describe the option in the vulnerability description.
Where compensating controls go
When you run a site-specific assessment, the same split applies on the consumer side. The FAQ says a built-in firewall filter can be represented with Modified Attack Complexity, and an external firewall filter with Modified Attack Requirements. Both belong to the Environmental group.
That means two copies of the same product can honestly carry different adjusted scores. The base score stays the vendor's. The modified values are yours.
Why this matters for triage
A flaw rated with Attack Requirements present is not automatically low priority. The metric tells you the attacker needs luck or position, not that nobody will try. Read it alongside exploitation evidence. If something is already being exploited, the conditions have evidently been met by someone.
When you review vendor vectors, look at AC and AT together with Privileges Required and User Interaction. A vector with network access, low complexity, no requirements, no privileges and no interaction describes a flaw an attacker can hit directly. That combination deserves a fast look even before any other data arrives.
Safeguard's reachability analysis helps with the other half of the question, whether the vulnerable code path is used in your application at all. See the exploitability check demo.
Quick check
Which metric would a race condition affect?
Attack Requirements, because it is an external condition of the target that must be satisfied.
Should an unusual vulnerable configuration raise Attack Requirements?
No. Assume the vulnerable configuration, and describe the setting in the vulnerability text instead.
Sources
Last reviewed: 19 October 2026.
