The CRA brings with it a whole lot of documentation requirements. While many details are still being finalised, we already know the core compliance artifacts you’ll need. Echoing the principle of security-by-design, the paper trail should begin at the design stage and continue well past decommissioning.
Regulations aside, documenting early and thoroughly is just good development hygiene. The CRA gives a solid nudge toward these practices and might even save you a scramble later.
Too often, documentation is an afterthought, gathered shortly before release. Security is bolted on, instead of built into the product. In the worst-case scenario, all issues are discovered in a penetration test days before the go-live date. The CRA flips that script: it demands security and traceability across the entire life cycle of a device.
This guide walks through the key compliance artifacts – when to create them, how to keep them useful, and how to streamline the process as part of real-world development.
PRE-DESIGN
Lay the legal and planning groundwork
Before design even starts, you will have a broad concept of what the product should be and what it should be able to do. As you plan timelines for the development of the product, plan documentation as part of that timeline. Versioning plans should be defined early. This is also the time to look at the CRA classification information and determine which category your product fits into. You can use the CRACoWi Scope Check for this This has a big impact on the path to compliance, as some devices can be self-assessed, others require a notified body to attest to your conformity. At this stage, you’re laying the legal and operational foundation for compliance – especially by identifying your CRA category and outlining what level of scrutiny your product will face.
This early classification also shapes how much documentation effort you’ll need to plan for. A product that falls into the default category may only require a lightweight internal documentation approach. But if you’re developing something that is likely to be considered a critical product – for example, a device that handles sensitive data or plays a role in infrastructure – the expectations will be significantly higher. Formal documentation processes, traceable decision-making, and structured risk assessments will all need to be in place from the beginning, because they will be reviewed during the final conformity assessment.
Start documenting early – the final assessment will rely on evidence you’ve built throughout the process.
DESIGN
Security as a design constraint
During the design phase, the CRA should be thought of as a design requirement. Both secure-by-design and secure-by-default are fundamental principles embedded in Annex I of the regulation and should be applied from the very beginning.
Secure-by-design means that security is not added as an afterthought – it’s embedded into the architecture and functionality of the product from the outset. Threat modelling, risk analysis, and defensive design choices should influence system structure, interfaces, and component selection.
Secure-by-default ensures that when the product is first activated, it is configured in a way that minimises exposure and risk – without requiring the user to make changes. This includes things like disabling unnecessary services, enforcing strong authentication out of the box, and avoiding insecure default settings.
It’s also at this stage that you should clarify who is responsible for maintaining documentation – including architecture decisions, threat assessments, and security design justifications – so that responsibility is clear from the start.
Taking security seriously at this point doesn’t just reduce risk – it improves the product itself. Security controls that are built into the design are more effective, better integrated, and far less costly than those retrofitted later. This shift-left approach not only reduces the time, complexity, and cost of CRA compliance, but leads to a more robust, maintainable, and trustworthy product overall.
Risk Assessment
Take a first pass at the risk assessment as soon as the concept and initial architecture are established. An ideal way to do this would be to hold a workshop with engineers and security. The functionality and connectivity of the device should be considered at this stage, but also distribution and delivery risks should be considered, such as secure elements, signed firmware, secure on boarding and upgrade procedures, key management schemes, and packaging and supply chain contracts. Once the design is finalised, a second pass can be made. We can already establish the risk register at this point.
SBOM
It is a little early to create the SBOM, but some important things can be put into place. Decide on tooling, pipeline integration, and format. Establish an update process and determine the scope for the SBOM. Does it need to cover firmware, the operating system, third-party libraries and cloud elements? When looking at tooling, select the ones that have the best support for your technology stack, as there are big differences in the coverage.Technical documentation
Technical documentation under the CRA is more than just paperwork – it’s the formal, structured evidence that your product complies with the regulation. It brings together all the security-relevant artifacts described throughout this guide – such as the SBOM, risk assessment, vulnerability management process, and testing results – into one comprehensive package. This documentation must cover the entire product life cycle and should include:
- Documented risk assessment and mitigation plan
- Up-to-date SBOM
- Defined vulnerability handling processes
- Your product’s security architecture and design decisions
- Evidence of implemented security controls (e.g., secure boot, encryption, access control)
- Testing and assessment results (e.g., code reviews, scans, penetration tests)
- Version history, change logs, and alignment with user documentation
The CRA (Article 23 + Annex II) requires this technical documentation to be maintained and updated throughout the product’s life and kept for ten years after it is withdrawn from the market. Start early. Set up the structure for your technical documentation during the design phase. Decide:
- What to include
- Who owns each section
- What tools and repositories will be used
Choose systems your team will maintain. Treat technical documentation as a continuous, integrated part of development – not a separate compliance silo that’s only filled in at the end.
User Documentation
Begin outlining your user documentation early. The CRA requires that security-relevant information is clear, accessible, and available at delivery – so plan what you’ll need to explain: update instructions, supported life cycle, security features, and contact for vulnerability reporting.Vulnerability Management
Determine a strategy, process and handling. Design this process so that it hooks into the SBOM and risk assessment. Set up vulnerability reporting mechanisms and a process for evaluating discovered vulnerabilities. Define how often the status will be reviewed, i.e. monthly, quarterly. Design the product with secure and fast patching in mind, and maintainability for the entire support period.
Testing
Formal testing doesn’t start here, but design-level reviews matter. Use threat modelling and architecture reviews to validate your security assumptions early. Even lightweight STRIDE analysis or data flow mapping can uncover risks that are easier to fix before implementation.
DEVELOPMENT
Build, test, document as you go
In the development phase, the documentation starts to take a more concrete form. As you approach release, prepare for conformity assessment.
Risk Assessment
As third-party libraries and frameworks are added, the attack surface grows. The risk assessment starts to intersect with engineering work. You can link the previously identified risks to specific security controls that are implemented. Threat modelling and light STRIDE analysis can be built into code reviews.SBOM
Start to generate the SBOM. If possible, this process should be automated. Regenerate the SBOM every time dependencies change and use versioning. For traceability, an SBOM can be created for each build or release.Vulnerability Management
Integrate vulnerability scanning into the build pipelines. Run scans on every build or release. Record scanning configurations, triage decisions, and patch timelines in the technical documentation. Make sure to setup a process and the tools to include all triage and patch records between releases. This will prevent frustration and rework. If you don’t already have them, this is the time to set up vulnerability disclosure and response processes.Technical Documentation
Begin populating your technical documentation with real evidence: implemented controls, SBOM versions, risk decisions, and early test results. Keep change logs and link mitigations to risks.User Documentation
Start drafting user documentation in parallel with feature development. Keep it aligned with actual functionality – especially around configuration, security features, and update processes. You’ll need to finalise this before market placement, so avoid leaving it all until the end.
Testing
Testing during development is where secure-by-design meets real-world implementation. Integrate SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) tools into your CI/CD pipeline to catch vulnerabilities as early as possible. Use SBOM-based scanners to monitor dependencies for known issues and ensure that every update triggers a fresh scan. Embed security in your code review process – reviewers should check not just for bugs, but for missing access controls, exposed secrets, or poor cryptographic practices. You don’t need a full threat modelling session for every change, but applying lightweight STRIDE analysis or data flow reviews during development is a powerful way to catch architectural issues early. The results of all these tests feed into your technical documentation and form the backbone of your eventual conformity assessment.
What about Penetration Testing?
The CRA doesn’t explicitly require penetration testing, and formal guidance is still evolving. However, manufacturers are expected to demonstrate that their products meet the essential security requirements in Annex I – and security testing is how you build that evidence. This might include static and dynamic testing, security audits, and – where appropriate – penetration tests. While not mandatory by name, penetration testing is strongly recommended for Class II or high-risk products. As CRA implementation matures and harmonised standards are adopted, the expectations for security testing will likely become clearer. For now, document your test plans, coverage, and results carefully, and treat testing as a key pillar of your technical documentation and conformity assessment preparation. If you’re looking for structured support, tools like CRACoWi can help guide and streamline the testing process – especially for teams working toward CRA alignment for the first time.
PRE-MARKET & DELIVERY
Lock it down and prep for CE marking
At this stage documentation should be well established, and you should be ready for compliance. Ensure that the product matches the secure design. Any supply chain or manufacturing changes must maintain CRA conformity.
The CE marking is the manufacturer’s declaration that the product complies with all applicable EU legislation – including the CRA, once it applies. It’s a visible sign of conformity that allows the product to be legally placed on the EU market. For CRA-covered products, the CE mark confirms that the essential cybersecurity requirements have been met, either through self-assessment or third-party certification, depending on the product’s classification.
Risk Assessment
Production and distribution processes can differ from what is modelled during design and development, and component substitutions, third-party manufacturing, secure handling procedures, and late design tweaks can also introduce new risks. Verify that the planned mechanisms are in place and check for last-minute changes.
SBOM
Lock down the final version and audit it against the production. SBOM generation tools should remain in place, to monitor components for changes and advisories post-release. The final SBOM should be the basis for vulnerability monitoring. Remember that you need to disclose any open-source libraries used, including licence and version.Vulnerability Management
Review and document the full vulnerability flow, checking it is aligned with CRA obligations. Test that the security disclosure process works and ensure reporting information is included in the user documentation.Technical Documentation
Finalise your documentation for conformity. This includes test reports, vulnerability handling workflows, finalised risk assessment, and your internal compliance checklist. Prepare your Declaration of Conformity and link to user docs. If you want a more guided approach, CRACoWi can help streamline this phase – aligning your outputs with CRA expectations and reducing last-minute gaps.Testing
Wrap up your security testing at this stage. This might include a full SBOM scan, targeted penetration tests, or an external security audit. Document the scope, results, and remediation actions – this evidence feeds directly into your conformity assessment. The CRACoWi wizard support you to understand which tests you may need and complete them directly.Authorised Rep & Importers
If you are outside the EU, appoint an authorised representative. Ensure importers/distributors meet CRA obligations.Compliance Assessment & CE Marking
Based on your product’s classification, you’ll either self-assess (Default or Class I) or undergo third-party review (Class II or Critical). This assessment confirms that your product meets the essential requirements in Annex I. The result is a signed EU Declaration of Conformity – and permission to affix the CE marking.Support/Maintenance
Stay compliant after release
After release, threat-monitoring, incident response, and vulnerability disclosure processes continue throughout the support period. Automatic security updates should be applied where required, and vulnerabilities must be patched promptly.
Under the CRA, timelines are tight: exploited vulnerabilities or actively exploited incidents must be reported within 24 hours to the EU-wide vulnerability database, and within 72 hours to national authorities where required. Ongoing compliance means staying responsive – and being able to prove it through maintained records and coordinated disclosure procedures.
Risk Assessment
This should be periodically updated. Consider changes to the environment and threat landscape, brought about by increased connection and new attack techniques. Use the risk assessment to prioritise vulnerabilities and decide on mitigations. Feed this information through to patching and documentation. Inform users and authorities, when required.SBOM
Use the SBOM to actively monitor for vulnerabilities. Update the document with every security update, firmware release, or component change.Vulnerability Management
Continually monitor internal sources for bugs, external sources for CVEs, and SBOM components. Assess each discovered vulnerability, log triage decisions, and patch with minimal delay. Maintain the vulnerability reporting channel.Technical Documentation
Keep your technical documentation alive during the support period. Every security update, patch, or vulnerability response should be recorded. If you issue new firmware, update the SBOM and testing evidence. CRA compliance includes traceability – so every change should be reflected in the documentation set.Testing
Repeat security testing after major updates. Keep scanning active during patching.Decommissioning
CRA doesn’t end at EOL
The CRA requires that end-of-life policies are clearly defined. Products should be securely decommissioned, or upgrade paths offered to supported versions. Documentation must be kept for ten years after the last product is placed on the market. Decommissioning isn’t the end of compliance – the CRA expects long-term accountability, even after your product is off the market.
