The Cyber Resilience Act (CRA) introduces two distinct conformity assessment procedures that manufacturers must follow before placing a Product with Digital Elements (PDE) on the EU market. Understanding which procedure applies to your product is one of the most important compliance decisions you will make.
This guide explains both conformity routes—Internal Control and Third-Party Assessment—in depth, including requirements, documentation, testing expectations, timelines, and the criteria that determine your conformity path.
1. What Is a Conformity Assessment Under the CRA?
A conformity assessment is the formal process used to verify that a digital product meets the Essential Cybersecurity Requirements in Annex I of the CRA. It includes:
- Technical documentation
- Security design and architecture evidence
- Vulnerability handling processes
- Secure update mechanisms
- Post-market monitoring plans
- Testing and validation results
You cannot place a product on the EU market without completing a conformity assessment.
2. The Two CRA Conformity Assessment Procedures
The CRA offers two routes:
- Internal Control (Self-Assessment) – available only for Default Class products
- Third-Party Assessment (Notified Body) – mandatory for Critical Class products
Your conformity route depends entirely on your product classification.
3. Internal Control (Default Class Products)
Internal Control is a self-assessment process that allows manufacturers to:
- Prepare technical documentation internally
- Conduct their own testing and validation
- Prepare an EU Declaration of Conformity
- Affix the CE marking without external review
This route applies to Default Class products, which represent standard-risk digital products.
3.1 Requirements of Internal Control
Manufacturers must:
- Create and maintain all technical documentation required in Annex II
- Perform security testing aligned with Annex I
- Implement secure update mechanisms
- Document vulnerability handling procedures
- Prepare a post-market monitoring plan
- Compile an EU Declaration of Conformity
Authorities may review this documentation at any time.
3.2 Who Can Use Internal Control?
Products that fall under the Default Class—meaning they do not meet any of the criteria for Critical Class—may use this route.
Examples include:
- Developer tools without direct safety impact
- General-purpose embedded controllers
- Consumer IoT devices not used in critical contexts
- Software applications that do not interface with critical systems
4. Third-Party Conformity Assessment (Critical Class Products)
If your product is classified as Critical Class, you must undergo a full review by a Notified Body. This is a significantly more rigorous process.
4.1 What the Notified Body Examines
A Notified Body will:
- Review your architecture documentation
- Review your secure development processes
- Conduct penetration testing or verify your test results
- Verify the correctness of your vulnerability management process
- Validate your secure update mechanism
- Assess your post-market monitoring design
- Ensure SBOM coverage and supply-chain monitoring
- Assess risk management decisions
The Notified Body may request revisions or additional testing.
4.2 When Third-Party Assessment Is Mandatory
You must undergo a third-party assessment if your product is considered Critical Class according to Annex III. This includes products where:
- Security failures could significantly disrupt critical infrastructure
- The product processes highly sensitive data
- The product manages industrial control or operational technology
- The product performs network security or gateway functions
If any Critical Class criteria apply, Internal Control is not allowed.
5. Comparison: Internal Control vs Third-Party Assessment
| Aspect | Internal Control | Third-Party Assessment |
|---|---|---|
| Eligibility | Default Class products only | Critical Class products only |
| Documentation | Self-prepared | Reviewed by Notified Body |
| Testing | Internal testing permitted | External testing or verification required |
| Timeline | Weeks | Months |
| Cost | Low | High |
| Regulatory Risk | Higher, if documentation is weak | Lower, due to external validation |
6. Documentation Requirements for Conformity Assessment
Annex II requires manufacturers to prepare extensive documentation, including:
- Product architecture
- Secure design principles
- Threat models
- SBOM (Software Bill of Materials)
- Update mechanisms
- Vulnerability handling workflows
- Security testing evidence
- Post-market monitoring plan
This documentation must be maintained for the full support period.
7. Key Steps of the Conformity Assessment Process
- Determine whether your product is Default or Critical Class
- Define your conformity route (Internal or Third-Party)
- Prepare Annex II technical documentation
- Perform security testing and validation
- Document all processes and evidence
- Complete EU Declaration of Conformity
- Affix CE marking
- Maintain documentation for authorities
8. Common Mistakes to Avoid
- Incorrectly assuming a product is Default Class
- Missing evidence for update validation
- Incomplete SBOM or dependency tracking
- Not documenting security testing
- Weak post-market monitoring plans
- Not preparing risk assessments or threat models
9. How Regulus Helps Manufacturers
Regulus simplifies CRA conformity by providing:
- Automatic Default vs Critical Class classification
- Conformity route selection
- Annex II documentation templates
- Security testing and validation checklists
- SBOM generation and monitoring
- Post-market monitoring workflows
Start by evaluating your product: CRA Applicability Checker
Conclusion
Choosing the correct conformity assessment route is essential for meeting CRA requirements. Default Class products may use Internal Control, but Critical Class products require third-party validation from a Notified Body. Preparing documentation early and aligning your security practices with Annex I ensures a smoother path to compliance.
For templates and guidance, visit our CRA Resources.
