About Beacon Standards
An open framework for categorizing and prioritizing security findings, published by Penti.ai under GPL-3.0.
The problem it addresses
Security teams do not struggle to find vulnerabilities. Scanners produce more findings than any organization can remediate, and the constraint has long since moved from detection to decision: which of these thousands of items should be worked on this week, and who should work on them.
The industry default is to sort by CVSS. This fails because the base score describes the vulnerability in the abstract and is therefore identical for every organization on earth. It cannot express whether the affected component is reachable, whether anyone is exploiting it, or what sits behind it — and published research has repeatedly found that remediating by score alone performs little better than working the list at random.
The deeper problem is that a severity rating is not an instruction. A finding marked High tells an engineer nothing about when it must be fixed, who owns it, whose budget it comes from, or whether it may legitimately be deferred. Beacon exists to supply exactly that layer, and to supply it consistently enough that two people classifying the same finding reach the same answer.
Six principles
A decision, not a score
A number is not a plan. Every Beacon classification resolves to a deadline, an owner, and an escalation path — the things that determine whether work actually happens.
Reachability before severity
The first question is whether an attacker can touch it. Score describes a vulnerability; reachability describes your exposure to it, and only one of those is specific to you.
Ordered, so it is repeatable
The four questions are asked in a fixed order. Consistency between analysts matters more than any individual analyst's judgement, because a taxonomy people apply differently is not a taxonomy.
Beyond the CVE
Misconfigurations, identity weaknesses, and process gaps carry no CVE and no CVSS score, and they account for most real exposure. A framework that only handles software vulnerabilities handles a minority of the problem.
Small enough to remember
Three tiers and four domains. Categorization schemes fail by growing — every additional category creates boundary cases, and boundary cases create arguments that cost more than the remediation would have.
Sourced or removed
Every quantitative claim on this site links to a public primary source. Where a number could not be traced to a report a reader can open and check, it was cut.
What the framework contains
Alongside the catalog the site publishes the decision procedure, an adoption guide, a comparison with CVSS, EPSS, KEV and SSVC, and a 20-term glossary. The catalog is also available as machine-readable JSON.
Who publishes and maintains it
Beacon Standards is published and maintained by Penti.ai. The framework originated at Securily, where it was developed out of penetration testing and vulnerability program work, and the public repository remains under that name.
It is released under GPL-3.0. The catalog, tier definitions, and framework mappings are public, and the machine-readable catalog is published specifically so it can be embedded in other tools. Corrections and additions are accepted through the repository — particularly disagreements about tier assignment, which are the most useful contributions the framework receives.
Finding identifiers are permanent. An entry may be reworded, re-mapped, or superseded, but its identifier is never reused or renumbered, so a citation in a report written today still resolves years from now.
Sources
Every quantitative claim on this site resolves to an entry here, and every entry names a public primary source. Figures drift between annual editions — each note records the edition it was taken from.
Exploitation of vulnerabilities as an initial access vector grew roughly 180% year over year
The 2024 DBIR reported that exploitation of vulnerabilities as a critical path to initiate a breach almost tripled from the prior year, driven substantially by mass exploitation of edge devices and file-transfer software.
Only a small minority of published CVEs are ever exploited in the wild
Successive volumes of the Cyentia/Kenna research found that roughly one in twenty published vulnerabilities is ever observed being exploited, and that remediating by CVSS score alone performs little better than remediating at random. This is the empirical basis for tiering on reachability and observed exploitation rather than on score.
The authoritative list of vulnerabilities confirmed to be exploited in the wild is a fraction of a percent of all published CVEs
The KEV catalog lists on the order of a thousand-plus entries against a published CVE corpus in the hundreds of thousands. Beacon treats KEV membership as a Tier 1 signal precisely because it is so much narrower than severity scoring.
Global median attacker dwell time is now measured in days, not months
Recent M-Trends editions report a global median dwell time of approximately ten days, down from over 400 days a decade earlier. Shorter dwell time reflects both improved detection and the rise of ransomware, which announces itself.
In ransomware intrusions the interval between initial access and encryption is frequently under 24 hours
Secureworks reported median dwell time before ransomware deployment falling to around 24 hours, with a meaningful share of cases completing in under a day. This is the basis for Beacon's 24-hour Tier 1 SLA: a remediation window longer than the attack window is not a control.
The global average cost of a data breach is approximately USD 4.9 million
The 2024 report put the global average at USD 4.88 million, its highest recorded figure. The same report consistently finds that shorter identification-and-containment cycles correlate with materially lower cost.
The human element is involved in roughly two-thirds of breaches
The 2024 DBIR attributed 68% of breaches to a non-malicious human element — error, privilege misuse, stolen credentials, or social engineering. This is why Beacon places MFA and privilege scope at Tier 1 alongside software vulnerabilities.
Contributing
The most valuable contributions are disagreements about tier assignment and finding classes the catalog is missing. Both belong in the repository, where the discussion becomes useful to everyone else applying the framework.