The situation
A connected device passes functional testing but ships with a configuration that has not been reviewed for unnecessary access. The security owner compares a gap record with an otherwise complete example where the default configuration has been checked and the accountable owner has reviewed the evidence.
Facts that change the answer
- What configuration reaches the customer before any optional hardening?
- Are unnecessary interfaces and permissions addressed?
- Which test and owner support the readiness confirmation?
Compare the worked results
These examples use the published assessment with the assumptions shown below. Change the facts in your own assessment before relying on its result.
Secure default configuration not confirmed
Hypothetical example 1
Key facts in this example
- Secure default configuration and a way to reset to the original state are addressed where applicable
- No
All recorded assumptions (22)
- Product with digital elements
- Hypothetical example product
- A documented cybersecurity risk assessment covers the product as a whole and remains updated
- Yes
- The product is designed, developed and produced to an appropriate cybersecurity level based on its risks
- Yes
- The release process checks that the product is made available without known exploitable vulnerabilities
- Yes
- Secure default configuration and a way to reset to the original state are addressed where applicable
- No
- Protection from unauthorised access through appropriate control mechanisms is addressed
- Yes
- Confidentiality of stored, transmitted and otherwise processed data is protected where applicable
- Yes
- Integrity of data, commands, programs and configuration is protected, and corruption is reported where appropriate
- Yes
- Only data adequate, relevant and limited to the product’s intended purpose is processed where applicable
- Yes
- Essential and basic functions remain available after an incident, including resilience and recovery measures where applicable
- Yes
- Measures minimise negative impact, attack surfaces and unnecessary externally accessible interfaces
- Yes
- Security-relevant activity can be recorded or monitored with an appropriate opt-out where required
- Yes
- Users are notified of available security updates, receive clear information after updates, and automatic security updates are enabled by default with an opt-out and recommended alternative mechanism where applicable
- Yes
- Users can securely and permanently remove their data and settings and, where applicable, transfer them to another product
- Yes
- Vulnerabilities and components are identified and documented, including an appropriate software bill of materials record
- Yes
- Vulnerabilities are addressed and remediated without delay, including through security updates where appropriate
- Yes
- Regular effective tests and reviews support product security and vulnerability handling
- Yes
- Information about fixed vulnerabilities, including description, identification, severity and impact where applicable, is published without undermining legitimate security interests
- Yes
- A coordinated vulnerability-disclosure policy is enforced and measures facilitate reporting and sharing information about vulnerabilities in the product and its third-party components, including a contact address
- Yes
- Security updates are distributed securely and without delay, free of charge unless the tailor-made business-product exception applies, with accessible advice about the fixed issue and user action
- Yes
- Technical documentation, EU declaration, support information and Annex II user information are assembled
- Yes
- An accountable product owner reviewed the completeness of this readiness record
- Yes
All readiness confirmations and owner review recorded
Hypothetical example 2
This is a management readiness result. Complete the conformity-assessment procedure applicable to the product before relying on a conformity claim or affixing the CE marking.(CRA Article 32 and Annex I)
Key facts in this example
- Secure default configuration and a way to reset to the original state are addressed where applicable
- Yes
All recorded assumptions (22)
- Product with digital elements
- Hypothetical example product
- A documented cybersecurity risk assessment covers the product as a whole and remains updated
- Yes
- The product is designed, developed and produced to an appropriate cybersecurity level based on its risks
- Yes
- The release process checks that the product is made available without known exploitable vulnerabilities
- Yes
- Secure default configuration and a way to reset to the original state are addressed where applicable
- Yes
- Protection from unauthorised access through appropriate control mechanisms is addressed
- Yes
- Confidentiality of stored, transmitted and otherwise processed data is protected where applicable
- Yes
- Integrity of data, commands, programs and configuration is protected, and corruption is reported where appropriate
- Yes
- Only data adequate, relevant and limited to the product’s intended purpose is processed where applicable
- Yes
- Essential and basic functions remain available after an incident, including resilience and recovery measures where applicable
- Yes
- Measures minimise negative impact, attack surfaces and unnecessary externally accessible interfaces
- Yes
- Security-relevant activity can be recorded or monitored with an appropriate opt-out where required
- Yes
- Users are notified of available security updates, receive clear information after updates, and automatic security updates are enabled by default with an opt-out and recommended alternative mechanism where applicable
- Yes
- Users can securely and permanently remove their data and settings and, where applicable, transfer them to another product
- Yes
- Vulnerabilities and components are identified and documented, including an appropriate software bill of materials record
- Yes
- Vulnerabilities are addressed and remediated without delay, including through security updates where appropriate
- Yes
- Regular effective tests and reviews support product security and vulnerability handling
- Yes
- Information about fixed vulnerabilities, including description, identification, severity and impact where applicable, is published without undermining legitimate security interests
- Yes
- A coordinated vulnerability-disclosure policy is enforced and measures facilitate reporting and sharing information about vulnerabilities in the product and its third-party components, including a contact address
- Yes
- Security updates are distributed securely and without delay, free of charge unless the tailor-made business-product exception applies, with accessible advice about the fixed issue and user action
- Yes
- Technical documentation, EU declaration, support information and Annex II user information are assembled
- Yes
- An accountable product owner reviewed the completeness of this readiness record
- Yes
Evaluated on 2026-09-13 using EU Cyber Resilience Act essential cybersecurity requirements readiness checklist, version 2026.09.02. A completed example is not a customer Record or a declaration of conformity.
Evidence to keep
- Versioned factory configuration
- Default-state access and interface tests
- Risk-based rationale and accountable readiness review
Keep source artifacts in their controlled systems and record their references, responsible owner and review date with the decision.
Your next step
Assign the configuration gap to the release owner and retain the test reference when it is resolved. A completed checklist supports review; it does not issue a conformity certificate.
Choose your real product or vulnerability case in the workspace. The selected assessment will be highlighted; example answers are not copied into your record.
Sources and application dates
- Regulation (EU) 2024/2847 (Cyber Resilience Act)Article 13; Annex I Parts I and II; Annexes II and VII
- European Commission CRA implementation guidance (2026)Sections 7–8 — product variants, remote data processing and risk assessment
Manufacturer reporting applies from 11 September 2026. Broader product requirements apply from 11 December 2027; these product-readiness examples support preparation. Open-source-steward obligations have their own application date.
These examples structure a decision and do not replace the Regulation, official guidance or product-specific professional advice. Not lawyer-reviewed.