Three deadlines, each starting a different clock. The first one already applies. Breaching manufacturer obligations, including reporting, can lead to fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.
11 September 2026WITHIN 24 HOURS
The obligation to report actively exploited vulnerabilities and severe incidents — early warning within 24 h and notification within 72 h of awareness, final report within 14 days of a measure becoming available (for an incident, one month from the notification).
11 December 2027FULL APPLICATION412 days
Conformity assessment, CE marking and technical documentation for products placed on the market from that date. The reporting obligation of 11 September 2026 also covers products sold earlier — including those already running at your customers.
10 yearsDOCUMENTATION RETENTION
Technical documentation and the EU declaration of conformity kept at the disposal of market surveillance authorities for at least 10 years after placing on the market — or for the support period, whichever is longer.
SBOMs, vulnerabilities, technical documentation and the auditor package
One place for the whole CRA evidence flow — from the composition of the product to the documents that go to an auditor and a market surveillance authority.
SBOM validation
Import and analysis of CycloneDX JSON 1.4–1.7 and SPDX JSON 2.3. Components, PURL identifiers, declared licences and dependencies checked automatically on every import.
Technical documentation
Annex VII, Annex II (instructions and information) and a draft of the Annex V/VI declaration — assembled from records that passed review. You get a ready draft that you sign and issue as the manufacturer.
Vulnerability tracking
A vulnerability linked to the release it actually affects. Impact assessment, a trace of the remediation decision and a register of reporting deadlines per version. Vulnerability data from OSV.dev, updated automatically.
Product versioning
Products and releases with full traceability. Artefacts, documents and vulnerabilities pinned to a specific release, not to the product in general.
Pipeline deliveries
Ready templates for GitHub Actions, GitLab CI and Jenkins — the SBOM is generated and delivered automatically on every release. The key works for a single release only, so a pipeline leak does not expose the rest of your data.
Reporting deadlines
Early warning at 24 h and notification at 72 h run from the moment of awareness. The final report is 14 days from the first qualifying measure for a vulnerability, and one calendar month from the notification for an incident. Every report has an owner and a deputy — a deadline is not missed because one person is on leave.
Retention and legal hold
Retention for the declared support period, suspension of deletion, and controlled deletion with separate approval.
External reporting inbox
A public intake point for researchers, anonymous submissions included, with acknowledgement of receipt and attachments scanned for malware.
Reporting drills
A controlled scenario on synthetic data: moment of awareness, decision, report content. Your team rehearses the 24 h clock with no risk of anything reaching an authority.
Duties and records by role
The Regulation puts different obligations on each party in the chain. The platform records the declared role and keeps evidence in the same structure for all of them.
1
Set up your organisation and products
We create the workspace, invite the team and describe the product boundary: main functions, update mechanism, connectivity and the role of the entity — manufacturer, importer or distributor.
2
Upload artefacts and evidence
SBOMs, technical documents, risk assessments and compliance evidence — separately for each version of the product, not in bulk for the product.
3
Monitor vulnerabilities
A vulnerability lands on the release it actually affects. Impact assessment, a decision to fix it or not, and a trace of who settled it.
4
Assemble the documentation
Annex VII, the EU declaration of conformity and instructions assembled from records that passed review. Empty sections stay visible as gaps.
5
Stay audit-ready
Retention for the declared support period, a full audit trail, and export of the evidence package on request from a customer or an authority.
1
Catalogue products and manufacturers
What you place on the Union market, who manufactures each product and in which version it enters circulation. The platform holds that register.
2
Collect evidence from the manufacturer
Confirmation of the conformity assessment, access to the technical documentation, the EU declaration of conformity and the manufacturer's details on the product.
3
Verify before placing on the market
A record of the completeness and currency check — with a date, a person and an outcome. That record answers the authority's question about why you placed the product.
4
Report non-conformities
A register of information passed to the manufacturer and to market surveillance authorities — every decision with its author, date and basis.
5
Keep documentation available
Documentation and correspondence available on request for the required period, with access control and a full audit trail.
1
Catalogue what you make available
What you make available on the market, where it comes from and which release it relates to.
2
Check marking and documents
CE marking, accompanying instructions and manufacturer information — before making the product available, not after a complaint.
3
Record the check
A record that the manufacturer and importer met their obligations, and that storage conditions did not compromise the product's conformity.
4
Act on non-conformity
A decision to stop making the product available, with its author and basis, and information to the manufacturer and notices to users — in one register.
5
Cooperate with authorities
A register of correspondence with market surveillance authorities and of material provided at their request.
Not sure which role you are in?Thirty minutes is enough to settle it — and to say what is a deadline and what can wait.
An audit does not ask about today’s state; it asks what changed and on what basis. Without a comparison, every release has to be proven from scratch.
Comparison of two releasesScope, requirements, materials and decisions of the old and the new version side by side. You see what was added, what disappeared and what was carried over without review.
Exploitability statementsVEX records with a trace of every state change: since when, on what basis and who decided that a vulnerability does not affect this release.
Remediation trackingPriority from severity, exposure and support, an assigned owner, and closure only after the fix is verified against a specific artefact.
Supplier queriesThe query sent, the answer received, the review and the acceptance — a register for when someone asks where a part of the product came from.
Documents the platform assembles for you
The CRA requires documentation to be kept for at least 10 years, or for the support period if that is longer. The platform assembles it from records that passed review — not from an empty template the week before an audit.
Annex VII — technical documentationProduct description, design and manufacture, risk assessment, support period, standards, test reports. Every section names the record it came from.
Annex II — instructions and informationProduct identification, intended use and risks, the contact point for reporting vulnerabilities, support and decommissioning.
Draft declaration — Annex V/VIManufacturer details, scope of the declaration, the statement to be signed, the signatory and the limitations — ready for your signature.
Auditor evidence packageAn export of scope, materials and decisions for one version, with a checksum manifest for every file and an optional digital signature — the auditor can verify nothing changed after export.
Vulnerability advisory in CSAF 2.0The machine-readable format your customers’ security teams expect, generated from the decisions actually recorded in the platform.
Exportable audit trailThe full history of actions in the organisation, downloadable as CSV — a ready answer to who made which decision, and when.
Documents are built from the data of a specific release. Empty sections show up at once as a list of gaps — you know what is missing before the auditor asks.
Built to be trusted with your data
Your customer's security team will ask these questions during vendor assessment. The answers are ready, and we will walk through the technical detail on a call.
Tenant separation at the database level
Each organisation's data is separated inside the database itself, and the application has no permission to bypass it. A bug in the code does not open another customer's data — the database blocks it.
Roles and separated permissions
Admin, contributor, reviewer, reader. Recording and approving are two distinct capabilities, granted independently and per product.
Multi-factor authentication
TOTP with secrets encrypted at rest, passwords hashed with bcrypt, login attempt throttling and a separate account recovery path.
Append-only history
A database trigger rejects any edit to a historical record. A correction becomes a new entry with its author and date, never an overwrite of the previous one.
Upload screening
Every material is scanned for malware before it enters the library. Document rendering runs in a separate, resource-bounded process.
Security headers and session protection
A CSP policy, CSRF protection, SameSite cookies and rate limiting on the login, API and upload endpoints.
Let's check whether this applies to your product
Thirty minutes. We say plainly whether the CRA covers you, which role you are in, what is a deadline and what can wait — and whether you need a tool for this at all.
