prEN 40000-1-3:2025 · Clause 5
Work the case. The audit pack writes itself.
Vulnerability handling for manufacturers who will be asked to prove it. Every requirement of the standard is encoded as data, and each one counts as satisfied only because a real artifact is linked to it, never because somebody ticked a box.
prEN 40000-1-3:2025 is a draft European standard and a candidate for harmonisation under the CRA; its enquiry closed on 5 March 2026. Until it is harmonised there is no presumption of conformity to be had, and this platform is not certified or endorsed by any standards or accreditation body.
The standard, encoded
79 items. 7 phases. One ID space.
This catalog is the only authority for requirement IDs in the platform, and it is versioned as data: when the draft becomes an EN, a tenant migrates a catalog version instead of waiting for a rewrite. Register a product and every item below is instantiated against it with an owner and an applicability decision: the to-do list arrives populated.
APP Applicability 1 item
- APP-1-RQ-01
PRE Preparation 43 items
- PRE-1-RQ-01
- PRE-1-RC-01
- PRE-1-RQ-02
- PRE-1-RC-02
- PRE-1-RQ-03
- PRE-1-RQ-04
- PRE-1-RQ-05
- PRE-2-RQ-01
- PRE-2-RQ-02
- PRE-2-RC-01
- PRE-2-RQ-03
- PRE-2-RC-02
- PRE-2-RC-03
- PRE-3-RC-01
- PRE-3-RQ-01
- PRE-4-RQ-01
- PRE-4-RQ-02
- PRE-5-RC-01
- PRE-5-RQ-01-RE
- PRE-5-RC-02
- PRE-5-RC-03
- PRE-5-RC-04
- PRE-6-RQ-01
- PRE-6-RQ-02
- PRE-7-RQ-01
- PRE-7-RQ-02
- PRE-7-RQ-03
- PRE-7-RQ-03-RE
- PRE-7-RQ-04
- PRE-7-RQ-05
- PRE-7-RC-01
- PRE-7-RQ-06
- PRE-7-RQ-07
- PRE-7-RQ-07-RE
- PRE-8-RQ-01
- PRE-8-RQ-02
- PRE-9-RQ-01
- PRE-9-RQ-02
- PRE-9-RQ-03
- PRE-9-RQ-04
- PRE-10-RQ-01
- PRE-10-RQ-02
- PRE-10-RQ-03
RCP Receipt 13 items
- RCP-1-RQ-01
- RCP-1-RQ-02
- RCP-1-RQ-03
- RCP-1-RC-01
- RCP-2-RQ-01
- RCP-2-RQ-02
- RCP-2-RQ-04
- RCP-3-RQ-01
- RCP-4-RQ-01
- RCP-5-RC-01
- RCP-6-RQ-01
- RCP-7-RQ-01
- RCP-7-RQ-02
VRF Verification 6 items
- VRF-1-RQ-01
- VRF-1-RQ-02
- VRF-2-RQ-01
- VRF-2-RQ-02
- VRF-2-RQ-03
- VRF-2-RQ-04
RMD Remediation 5 items
- RMD-1-RQ-01
- RMD-1-RQ-02
- RMD-2-RQ-01
- RMD-2-RQ-02
- RMD-3-RQ-01
RLS Release 10 items
- RLS-1-RQ-01
- RLS-1-RQ-02
- RLS-1-RQ-03
- RLS-1-RQ-04
- RLS-2-RQ-01
- RLS-2-RQ-02
- RLS-2-RQ-03
- RLS-2-RQ-03-RE
- RLS-2-PM-01
- RLS-2-RC-01
PRA Post-release 1 item
- PRA-1-RQ-01
50 mandatory14 recommended10 conditional4 risk-gated1 permitted pren-40000-1-3-2025-clause-5 · 0.1.0
Marked cells are the risk-gated enhancements: they apply only where a product's risk determination switches them on, which is why they are the only items whose applicability is not the same for everybody.
How it holds up
Four mechanisms. Each one can say no.
Evidence
Status is computed, never ticked.
A requirement is satisfied because an artifact is linked to it and that artifact has not expired. Let the evidence go stale and the item returns to being a gap, loudly. There is no done flag to set, not in the interface and not in the database behind it.
Guards
A refusal names the requirement.
The case state machine takes its guards from the standard. A blocked transition says what is missing and which item demands it, before the button is pressed rather than after.
Emission
Handling the case is the paperwork.
Acknowledge a report, match it against the SBOM, score it, decide, remediate, validate independently, release, publish the advisory. Each guarded step links its own evidence to the requirements it satisfies, so the audit pack fills up while the work is done, not in the week before an audit.
Integrity
The pack proves itself offline.
The report cites a SHA-256, the evidence index lists the same SHA-256, and the packaged file hashes to it. The pack opens from a local file with no network, carries no scripts, and prints to A4.
| report.html | cites | sha256 |
| evidence_index.csv | lists | sha256 |
| policy-v1.2.pdf | hashes to | sha256 |
Who it is for
The manufacturers who never had a PSIRT.
Large vendors have product security teams. The long tail of hardware and IoT manufacturers does not, and now faces a standard written in PSIRT vocabulary, a hard deadline, and nothing on the market between a spreadsheet and an enterprise GRC suite that has never heard of a coordinated-disclosure policy.
Export-oriented hardware ODM/OEMs
Networking, optics, IoT, industrial. 50 to 2,000 people, EU revenue at stake, no formal PSIRT. They need the process and the evidence, quickly, in the language they work in.
SME device makers selling into the EU
Under 200 people, security handled part-time. One person holding both the PSIRT-manager and duty-officer roles is a supported configuration here, not a workaround. That includes inviting the second pair of eyes the standard requires before a fix can be released.
Suppliers under CRA trickle-down
Component and module makers whose customers demand CRA-aligned vulnerability handling by contract. The questionnaires and the audits arrive before the law does.
Where it runs
On our own servers, in containers we operate. Unpatched, embargoed vulnerability data never sits on third-party managed infrastructure, and evidence files are stored in per-tenant partitions, fingerprinted with SHA-256.
Tenant isolation
Reading tenant data without naming the tenant raises an exception. A forgotten filter is a crash during development rather than a leak in production, and the isolation is asserted by tests on every build.
Two languages, one source
繁體中文 and English come out of the same records, so the version your engineers work in and the version an EU authority reads cannot drift apart. Advisories, assessment reports and the audit pack are all produced in both.
Limits
Stated plainly.
- The standard is still a draft. Conforming to a harmonised standard grants presumption of conformity. prEN 40000-1-3 is a candidate, not yet harmonised, so that presumption does not exist today. The catalog is versioned as data precisely so the change is a migration rather than a rebuild.
- We are before the first pilot tenant. The build is complete and under hardening. Onboarding is direct and high-touch by decision: there is no checkout, and there will not be one until the assessment product has proven itself on real work.
- No billing, no SSO, no public API yet. All three are on the backlog, behind the things a manufacturer needs to survive an audit. Ask if one of them is a condition for you.
- The 繁體中文 wording is machine-drafted. Interface strings and the translated requirement text are first drafts pending native review. Where a translation has not been reviewed we would rather say so here than have you discover it in front of an auditor.
Start with one product.
Create a workspace, register a product, and the full requirement list is instantiated against it. Nothing exists until you follow the confirmation link we send you.