Join our Mailing list!
Get all the latest news, exclusive deals, and feature updates.
— days until Article 14 applies
Cyber Resilience Act · Article 14 · Applies 11 September 2026
The CRA gives you 24 hours. Your CVE feed gives you weeks
SBOM, exploitation intelligence, risk exceptions and remediation are one pipeline in Phoenix, not four compliance projects. Here is how Purple, Orange, Blue, Blue Shield and Green produce an Article 14 declaration you can defend.
Article 14 reporting cascade
Awareness gap
Exploitation begins. The clock has not started because nobody has noticed.
T+24h
Early warning filed through the ENISA Single Reporting Platform.
T+72h
Full notification: nature of the flaw, corrective and mitigating measures.
T+14d
Final report once a corrective measure exists. One month for severe incidents.
The red segment is the part no regulation measures and every programme lives in. Article 14 starts counting at awareness, and awareness is a detection capability rather than a filing process.
The problem
Three regulators, three clocks, one set of facts
An actively exploited flaw in an inference service sold to an EU bank fires all three at once. Only a shared register keeps the three statements consistent.
CRA Article 14 — 24h / 72h / 14d.Manufacturers placing products with digital elements on the EU market. Filed through the ENISA Single Reporting Platform from 11 September 2026.
DORA Article 19 — 4h / 72h / 1 month.Major ICT incidents in the financial sector, classified under RTS 2024/1772 and reported under RTS 2025/301.
AI Act Article 73 — 15 days / 2 days.Serious incidents involving high-risk AI systems. Two days where infringement is widespread, 10 days on death.
See the full regulatory comparison (9 regimes)The gap
Why a CVE-shaped programme misses the trigger
Article 14 does not fire on vulnerable. It fires on actively exploited. Five gaps sit between those two words.
01
Enrichment outlives the deadline
A CVE is reserved, published, then enriched with CVSS and CPE. Those steps are not simultaneous. Until the record can be matched to an inventory, nothing reaches the triage queue.
02
Exploitation is not a CVE field
The signal arrives from KEV, EPSS movement, ransomware reporting and proof-of-concept publication. Correlating those by hand, per CVE, inside a day does not scale.
03
Malicious packages never get a CVE
A typosquat, a maintainer takeover or a registry-only payload is a live compromise inside your build. NVD will never carry it, because malware is not a vulnerability record.
04
Repositories are not releases
The regulator asks which products placed on the EU market contain the component, in which version, shipped to whom. An inventory keyed to repositories answers an adjacent question.
05
VEX is authored, not generated
Someone has to determine the vulnerable function is unreachable, or that a control already covers it, and be accountable for that call. Security teams have been filing those decisions for years.
The platform
One pipeline, five stages, one evidence chain
The order follows the platform philosophy: context first, prioritisation second, agent assistance third. Risk = Exploitability + Exposure + Reachability + Business Context.
| Stage | Question it answers | Module |
|---|---|---|
| Generate | What is in the product, including its models | Purple |
| Correlate | Is any of it being exploited or compromised right now | Blue · Blue Shield |
| Attribute | Which products and versions contain it, and who owns them | Orange |
| Declare | What is our exploitability position, and who signed it | Orange · Purple |
| Remediate | What corrective measure shipped, and how fast | Green · Orange |
Phoenix Purple
Code analysis · Inventory
Phoenix Orange
Inventory · Ownership · Declaration
Phoenix Blue
Intelligence · Exploitation evidence
Phoenix Blue Shield
Enforcement · Prevention
Phoenix Green
Remediation · Corrective measures
Phoenix Purple
Code analysis · Inventory
Graph-native SAST and SCA. Builds the component picture from the code and build, and traces findings to the change that introduced them.
- Static reachability establishes whether a vulnerable function sits on a call path
- Code Navigator traces the finding to its origin in the codebase
- Model, dataset and prompt inventory for AI-BOM and ML-BOM
CRA roleAnnex I §2(1) inventory depth, and the technical basis for a
not_affected justification.Phoenix Orange
Inventory · Ownership · Declaration
Where the declaration is assembled. CycloneDX SBOMs ingest directly and enrich on the way in, alongside connectors for more than 40 commercial and open-source scanners.
- Build-file pivot: one asset per
pom.xmlorpackage.json, keyed to its repository - PYRUS ownership attribution maps each component to an accountable team
- Four risk exception types under policy control, with expiry
CRA roleAnswers which products placed on the market contain a version, and holds the signed exploitability decision behind every VEX statement.
Phoenix Blue
Intelligence · Exploitation evidence
The awareness layer. Assembles the picture a reporting decision needs instead of treating the CVE record as the unit of truth.
- CISA KEV, VulnCheck, EPSS, OSV, GHSA, CSAF producers and ENISA's own EUVD
- Malware Package Intelligence: three independent stages before any verdict
- Commit-diff monitoring surfaces patches before CVE assignment
CRA roleEvidences the actively exploited condition that starts the clock, and its absence when you decide not to file.
Phoenix Blue Shield
Enforcement · Prevention
The same intelligence applied as a gate at four surfaces, in audit, warn or enforce mode.
- Workstation shim in front of
npm installandpip install - Native CI/CD plugins against lockfile and SBOM diffs
- Hooks into supported AI coding agents, before a dependency-add becomes a command
CRA roleEvery block is a notification never filed, because the shipped product never contained the component.
Phoenix Green
Remediation · Corrective measures
The 72-hour notification asks for corrective and mitigating measures. The 14-day report closes only when a corrective measure exists. Green produces both.
- Fix bundles cluster related findings into one remediation unit
- Tier ladder from Core through Plus and Plus Autofix to Premium
- Compensating-controls catalogue for the window before an upstream fix lands
CRA roleSupplies the corrective measure for the 72-hour and 14-day filings, and the evidence behind a
not_affected statement.See it on your data
Want to see this against your own inventory?
Bring your SBOM. We'll run it through the same five stages and show you where the gaps are, before September does it for you.
Declaration
Your exception register is already a VEX document
Publishing an SBOM without VEX hands customers and market surveillance authorities a false-positive generator with your name on it.
The correction is a decision your team already makes. It just needs a place to be signed.
| Phoenix exception | What the team decided | VEX equivalent |
|---|---|---|
| False positive | Vulnerable code not present or not reachable here | not_affected |
| Mitigation | A compensating control is already in place | not_affected · mitigation |
| Risk acceptance | Real, understood, consciously not fixed now | affected · will not fix |
| Risk recasting | Real, but severity differs in this context | affected · adjusted |
| Remediated finding | Fixed in this version | fixed |
T+0
BlueExploitation evidence lands, or a malicious package is confirmed. Campaign and repeat-offender context attaches to the verdict.
T+2h
OrangeAffected products, versions and owners resolved through the build-file pivot and ownership attribution.
T+6h
PurpleOrangeReachability and exposure assessed. Exploitability position drafted against the affected component.
T+24h
OrangeEarly warning filed through the ENISA Single Reporting Platform from the register.
T+72h
GreenFix bundle or compensating control identified. Corrective and mitigating measures stated.
T+14d
GreenOrangeCorrective measure shipped, exception records reconciled, final report filed.
Proof
Why triage volume is a compliance metric
A 24-hour decision needs a surface small enough for a person to reason about, with an owner attached to every row.
<8,000
Actionable items from 467,000 container vulnerabilities via lineage analysis
Container estatesPlatform status
In the platform today, and direction
Knowing at 03:00 that a package in your build was compromised four hours ago is the part no schema provides.
In the platform
Machine-readable component inventory
CycloneDX SBOM ingest into Orange
Vulnerabilities matched to components
CVE enrichment on every ingested dependency
Evidence of active exploitation
Blue: KEV, VulnCheck, EPSS, EUVD
Malicious dependency detection with no CVE
Blue Malware Package Intelligence
Preventive enforcement at install, CI and agent
Blue Shield, four surfaces, three modes
Time-bound, approved, audited exceptions
Orange exception engine, four types
Corrective measures and compensating controls
Green fix bundles, autofix tiers
Register extract for auditors and RFIs
CSV and JSON findings export
Direction
Blue verdicts enriching Orange library rows
Existing intelligence joined onto existing inventory
SBOM publication in SPDX 3.0
Serialisation of the inventory Orange holds
VEX export in CycloneDX VEX or CSAF 2.0
Serialisation of the exception and reachability register
AI-BOM and ML-BOM emission
Extension of Purple component inventory
Per-product CRA readiness scorecard
Coverage, exception hygiene, declaration readiness
Self-check
Four questions worth answering while there is still time to be wrong about them
Can you enumerate what you shipped, per version and per customer, not just per repository? Where does your exploitation signal actually come from, and is the honest answer "we wait for the CVE"? Can you see attacks that never get a CVE at all? And are your exception decisions structured, or sitting in a spreadsheet — because on 11 September, that spreadsheet becomes a regulatory statement.
— days until Article 14 applies
Next step
The clock is not counting down to a document.
It is counting down to a question
Run the 24-hour tabletop against an event from your own history, using a malicious-package incident rather than a CVE, since that is the trigger most programmes cannot see.
Trusted by security teams at
