What to keep in the product file
Cyber Resilience Act document
A useful Cyber Resilience Act document is not one file. It is a living product pack that connects product classification, engineering evidence, vulnerability handling, and conformity statements.
Need the operational version?
What to do with this information
- Scope memo: why the product is in or out of scope, target market, deployment model, and product category.
- SBOM: SPDX or CycloneDX output with component names, versions, suppliers, licenses, and dependency relationships.
- Vulnerability record: CVE matches, severity, exploitability notes, remediation decision, and release reference.
- Article 14 templates: notification records with timestamps, impact summary, mitigation state, and follow-up owner.
- Declaration draft: EU Declaration of Conformity fields, product identification, manufacturer details, standards references, and sign-off trail.
How CertCore uses it
CertCore generates these documents as connected artifacts so a version update can trigger re-checks instead of creating a fresh compliance scramble.
Official and technical references
Questions teams ask
Is one CRA document enough?
Usually no. Treat the document as a product evidence pack that changes when the product or dependency graph changes.
Which SBOM formats should we keep?
SPDX and CycloneDX are the most common machine-readable formats for software dependency evidence.
When should documents be refreshed?
At release, after dependency changes, after material vulnerabilities, and before conformity review.