Attacker Friction Rating: A Better Question for Security Metrics
Most scoring models used by security teams today focus on findings. CVSS shows how serious a flaw is. EPSS predicts how likely it is to be exploited. SSVC helps decide if you should act now or later. All three answer the same question: what should we fix first?
But none of these models answer the question leaders really care about: is our environment harder to attack this quarter than it was last quarter?
Having fewer open issues doesn't always mean your environment is more secure. You could close thousands of findings and still leave all the important attack paths untouched.
Before we go further, let's be clear: while adversary friction is a familiar idea, "Attacker Friction Rating" isn't an industry standard. There's no official specification, peer-reviewed method, or vendor product for it yet. What follows is just a proposed model, not an established practice. I'm sharing it because I think it answers the right question, and I'd rather get open feedback than keep refining it privately.
The problem isn't with the tools — it's built into the way we measure things
We measure by findings, so teams get rewarded for fixing lots of issues. Your vulnerability management program tracks a number that drops as people patch things, and that's the number that gets shown in reports.
But the controls that really change how attackers behave often don't affect the vulnerability count much:
- Network segmentation
- Privileged access management
- Phishing-resistant authentication
- Detection engineering
With finding-based metrics, these investments seem invisible. If you spend a quarter securing service accounts and separating user and file tiers, you might not close any findings. But if you spend the same time patching low-risk CVEs on systems that attackers don't use, you could close thousands.
The metric ends up focusing on the wrong things, and everyone involved can sense it, even if they can't quite explain why.
What AFR measures
Attacker Friction Rating focuses on attack paths instead of individual findings. It measures how much cost, time, skill, and risk of being detected an attacker faces when moving from an outside starting point to something important to the business.
Each area gets a score from 1 to 5, with 5 being the most friction. The weighted average is then converted to a 0 to 100 rating.
| Dimension | What it measures | Weight | Primary data source |
|---|---|---|---|
| Enforcing controls in path | Count of controls along the path that block the required action, as opposed to controls that only observe and alert | 30% | Control inventory, firewall and identity policy review |
| Detection coverage | Percentage of the MITRE ATT&CK techniques the path requires that you have validated detection content for | 25% | SIEM, EDR, and NDR detection content |
| Credential transitions required | Number of distinct identities the adversary must obtain, and the difficulty of obtaining each one | 20% | Identity provider, PAM platform |
| Path length | Hop count from untrusted origin to the target system. More hops means more opportunities to detect and interdict | 15% | Network topology, segmentation policy |
| Estimated time to detect | Expected elapsed time between the adversary's first action on the path and your first actionable alert | 10% | Historical incident data, purple team results |
You score each path individually, then combine the results across a set of chosen paths for reporting.
The first area is more important than it seems. A control that blocks an attacker forces them to change their approach. A control that only alerts your SOC changes what your team does, not the attacker. Both are useful, but only blocking controls add friction to the attack path, and most inventories don't separate the two.
Score bands
| AFR score | Band and interpretation |
|---|---|
| 0–25 | Frictionless. A competent adversary reaches the target with commodity tooling and no meaningful obstruction. |
| 26–50 | Low. Obstacles exist but are bypassable with known techniques. Detection is retrospective rather than interdicting. |
| 51–75 | Moderate. The path requires deliberate effort, multiple credential acquisitions, and carries real detection risk. |
| 76–100 | High. The path is expensive, slow, and likely to be caught in progress. A rational adversary looks for a different route. |
These bands describe how attackers weigh their options, not compliance levels. The goal of the highest band isn't to be "secure," but to make a smart attacker look for an easier target. That's what defensive investments really achieve.
A worked example
Here's an example: an outside attacker targets a Tier 1 loan servicing app. The attack path starts with a phishing email, then uses stolen credentials approved by push notification, moves to a file server on a flat network, grabs a cached service account credential, and finally reaches the target application.
The change being measured is one quarter's work: adding phishing-resistant MFA for remote access, separating user and file tiers, and securing the service account in a vault.
| Dimension | Before | After | What changed |
|---|---|---|---|
| Enforcing controls in path | 1 | 4 | Phishing-resistant MFA replaces push approval. Segmentation added between the user tier and the file tier. Service account moved into vaulted checkout. |
| Detection coverage | 2 | 4 | Identity analytics on anomalous vault checkout added to existing endpoint coverage. |
| Credential transitions required | 2 | 4 | Service account credential is no longer resident on the file server and must be checked out under approval. |
| Path length | 3 | 4 | Segmentation forces an additional pivot that did not previously exist. |
| Estimated time to detect | 1 | 3 | Estimate moves from days to hours because the vault checkout is a high-signal, low-volume event. |
| AFR (weighted, scaled to 100) | 35 | 78 | Low friction to High friction. A 43-point improvement on a single path. |
The point of the example
In this scenario, no vulnerabilities were fixed. The number of findings stayed the same before and after. If you only look at CVSS-based reports, it looks like nothing happened that quarter.
But with AFR, that quarter's work moved a key attack path from low friction to high friction, clearly changing what an attacker would need to do to reach a Tier 1 system.
That's the reporting gap AFR fills. It gives projects like segmentation, PAM rollouts, and detection engineering a number that actually changes when they succeed. This is what lets those efforts compete with patching for budget and attention.
Limitations worth stating up front
The quality of scoring depends on how well you can see attack paths. If you can't map a path, you can't score it. Not being able to map a path doesn't mean it's high friction, and this model could give a false sense of security if you forget that.
The scores are ordinal. For example, a 78 isn't "twice as good" as a 39. You shouldn't average AFR scores across different paths or present one overall number. Instead, report the range of scores and how individual paths change over time.
Time to detect is the weakest part of the score because it's usually estimated, not measured. That's why it gets the lowest weight. As you get real results from purple team exercises, use those instead of estimates.
AFR is meant to add to, not replace, existing prioritization models. CVSS, EPSS, and SSVC are good at telling you what to fix first. AFR isn't for picking which specific issue to fix — it answers a different question for a different group of people.
What it takes to operationalize
Four things, none of them exotic:
- You need an agreed set of attack paths — a list of five to ten key paths to your most important systems that you'll score every quarter. Focus on the ones that matter most, not every possible path.
- You also need a scoring guide with clear definitions for each 1-to-5 value in every area. This way, two analysts scoring the same path will get similar results. Without this, the model just becomes guesswork with numbers.
- Set a quarterly schedule that matches your control roadmap. Changes in friction should be linked to specific projects. The goal is to be able to say, "This path went from 35 to 78 because of these three projects."
- You'll also need a version for the board: show the change in friction for each path, along with the control investments that caused those changes. This lets you answer "are we harder to attack than last quarter" with real data, not just a finding count.
An invitation, not a standard
AFR is just a proposal. The weights can be debated, the dimensions might not cover everything, and the scoring anchors need to be tested in real situations by real teams. If you work in threat-informed defense, purple teaming, or security metrics and spot a flaw in the model — or if you've built something similar yourself — I'd love to hear your thoughts.
Three strong frameworks have already answered the finding-based question in different ways. The path-based question is still open, and this is one way to approach it.