"The risk is high." — When asked how that value came about, most risk assessments respond with silence or a reference to experience. That is not a rating scale, it is an opinion with a color code. Two people on the same team would reach different results, and in an audit the decision cannot be traced.
For the question "how realistic is this attack in the first place?", a well-thought-out, reproducible methodology has existed for years: the attack potential rating from the Common Criteria methodology, published as ISO/IEC 18045.
Five factors instead of a gut feeling
The method breaks the feasibility of an attack down into five factors, which are assessed individually and then summed into a numerical value:
| Factor | The question behind it |
|---|---|
| Elapsed Time | How long does the attacker need — hours, weeks, months? |
| Expertise | Is layman knowledge enough, is specialist knowledge required, or several areas of expertise? |
| Knowledge of TOE | Is knowledge of the target of evaluation public, restricted, sensitive or critical? |
| Window of Opportunity | How much access is needed, and how easy is it to obtain? |
| Equipment | Standard tools, specialized equipment, or bespoke hardware? |
The appeal lies in the decomposition itself. You can argue about "is the risk high?"; you cannot argue about "does the attacker need physical access to the opened device?". The question turns from a matter of judgment into a matter of fact — and factual questions can be answered consistently by a team.
From factor values to resistance
Summed up, the five individual values give the attack potential: the effort an attacker has to invest. This value is then translated into a statement about the resistance of the target of evaluation — the higher the required potential, the more resistant the product is against this specific attack.
In the methodology, this is found in Annex B: B.6 describes the calculation, and the associated tables provide the point values per factor level and the translation into resistance. In certification schemes, this is exactly the lever that determines the level achieved — under EUCC, for example, the vulnerability analysis (AVA_VAN) drives the assurance level.
What the method does not do
This is where the most common misunderstanding lies: attack feasibility rates the likelihood side, not the damage. An attack can be trivial to carry out and still be irrelevant — or extremely costly and existentially threatening.
Only the combination of both sides yields a risk. The impact side therefore needs its own, separate methodology — typically based on damage categories such as safety, financial damage, operational disruption, legal consequences and data protection. The two are combined at the end, usually via a matrix.
Anyone who mixes both sides ends up with a number that no longer means anything.
Three things that make the difference in practice
Calibrate once, together. The factor levels are descriptions, not measured values. Whether "days" or "weeks" applies will be judged differently by two engineers — as long as they have not worked through it together once on the actual product. One hour of calibration at the start saves every later discussion about comparability.
Document the rationale, not just the value. In an audit, the point value alone is worthless. It becomes traceable through the sentence explaining why this level was chosen — "access only with the control cabinet open, sealed during operation" is an argument, "3" is not.
Do not calculate to the decimal place. The method does not produce a physical measured quantity, but a robust ranking. Its purpose is to answer the question "what first?" in a justifiable way — not to quantify risks to two decimal places.
Why the effort pays off for device manufacturers
The practical benefit shows less when creating the rating than when defending it. When a customer, an auditor or a certification body asks why a vulnerability was classified as low priority, the answer is either a traceable calculation — or a recollection of a meeting two years ago.
And because the methodology is established and documented, you do not have to defend it. You only have to show that you applied it consistently.
Sources
- CEM:2022 Release 1, Annex B — Vulnerability assessment (AVA), B.6 Calculating attack potential
- ISO/IEC 18045:2026, Edition 4.0 (2026-05-19)
This article was originally published in German on the Alsensio Cybersecurity Hub.
