CTO

The CTO problem

You built the product. Now you need to know: does CRA apply? If yes, is it Default or Important Class I or Important Class II? What does Annex I actually require from your architecture? Can you self-certify, or do you need a notified body?

Legal can tell you CRA applies. Legal cannot tell you whether your firmware update mechanism satisfies CRA Annex I Part I §2(7) ("secure updates, integrity verification, rollback"). That is an engineering question. You need the article-level obligation mapped to your product, not a summary of what the regulation says.

What NexCyber gives CTOs

Scope determination — in 60 seconds

Is your product a "product with digital elements"? Is it Default, Important Class I, or Important Class II? What conformity assessment route does that require?

The CRA Scope Checker gives you an In Scope / Likely / Not In Scope / Borderline verdict in 60 seconds based on 6 questions. No login required.

If you are also subject to the AI Act, the AI Act Risk Classifier classifies your AI system and identifies which cybersecurity obligations overlap with CRA.

Annex I Part I — security requirements mapped to your architecture

CRA Annex I Part I lists 13 essential cybersecurity requirements for products with digital elements. NexCyber maps each to specific engineering controls:

| CRA Annex I Part I | Engineering control | |---|---| | §2(1) No known exploitable vulnerabilities at market placement | Dependency scanning in CI, vulnerability database check pre-release | | §2(2) Secure default configuration, no universal default passwords | Config hardening, unique device credentials | | §2(3) Protection against unauthorised access | Authentication, RBAC, MFA where applicable | | §2(4) Protect confidentiality of data | Encryption in transit (TLS 1.2+) and at rest | | §2(5) Minimise attack surface, disable unused interfaces | Network interface audit, port closure, feature flags | | §2(6) Reduce impact of security incidents | Isolation, containment, audit logging | | §2(7) Record and monitor security-relevant data | Log collection, SIEM integration, retention policy | | §2(8) Correctable: security updates | OTA update mechanism, signing, rollback | | §2(9) Security by default | Hardened defaults, no opt-in required for security controls | | §2(10) Resilience against DoS | Rate limiting, resource quotas | | §2(11) Minimal data collection | Privacy by design, data minimisation | | §2(12) Protect integrity of user data | Integrity verification, tamper detection | | §2(13) Auditability | Audit log, forensic capability |

Annex I Part II — SBOM and vulnerability management

CRA Annex I Part II requires:

1. SBOM: machine-readable, covering all third-party components to transitive depth. SPDX 2.3/3.0 or CycloneDX 1.5 both satisfy requirements.
2. CVD policy: publicly accessible coordinated vulnerability disclosure process
3. Vulnerability handling: identify, document, remediate, and notify within CRA timelines

→ SBOM under CRA — SPDX vs CycloneDX, depth, signing

Conformity assessment route selection

| Product class | Route | Notified body | |---|---|---| | Default class | Self-assessment (internal production control) | Not required | | Important Class I | Self-assessment using harmonised standard OR third-party assessment | Optional if harmonised standard applied | | Important Class II | Third-party assessment by notified body | Required | | Critical class | European cybersecurity certification scheme | Required |

Most software products and Class I IoT devices qualify for self-assessment using harmonised standards.

→ Audit-ready evidence for CRA

RED Article 3(3) — for IoT and radio equipment

If your product is internet-connected radio equipment, RED Article 3(3) applies from 1 August 2025. ETSI EN 303 645 is the harmonised standard. Self-assessment via CE marking.

The good news: ETSI EN 303 645 and CRA Annex I overlap on 6 provisions. Implementing EN 303 645 now creates the foundation for CRA compliance in 2027.

→ RED Article 3(3) cybersecurity for IoT

Key architecture decisions triggered by CRA

1. Firmware update mechanism — must be signed, integrity-verified, with rollback capability (Annex I §2(8)). If you don't have this, build it now.
2. SBOM generation in CI/CD — manual SBOM creation does not scale. Automate with Syft, cdxgen, or equivalent. Output SPDX or CycloneDX.
3. CVD policy + monitored channel — a security@ alias monitored by a named person, with defined response SLA.
4. Vulnerability log — structured record of every vulnerability discovered, triaged, and remediated. Format: CVE ID, severity, affected version, fix version, disclosure date, ENISA notification if applicable.
5. Secure defaults — audit every default configuration before release. Universal default passwords are explicitly banned.

Tools

• CRA Scope Checker — product scope + class determination
• SBOM Readiness Checker — Annex I Part II completeness
• AI Act Risk Classifier — AI system classification
• EU Market Access Score — cross-regulation readiness score

Related answers

• SBOM under CRA
• CRA Article 14 vulnerability reporting
• RED Article 3(3) IoT compliance
• AI Act × CRA overlap

NexCyber — EU Market Access Compliance Platform