Defence in Depth

Defence in depth is a security architecture principle derived from military strategy: rather than relying on a single defensive line, multiple overlapping layers of protection are deployed so that an attacker must defeat all layers, not just one. In product security, this means combining multiple different types of security controls — physical, firmware, OS, application, network, monitoring — such that the compromise of any single control does not lead to full system compromise. The term recognises the reality that no single security control is perfect: attackers will find flaws in any individual mechanism. Defence in depth ensures that flaws in one layer are compensated for by other layers, limiting the blast radius of any individual failure.

The CRA's Annex I essential requirements collectively implement a defence-in-depth approach to product security. No single requirement is presented as sufficient — the requirements span multiple layers:

• Hardware layer: Secure boot, hardware-backed key storage, physical interface lockdown.
• Firmware/OS layer: Least privilege, process isolation, memory protection.
• Application layer: Input validation, authentication, authorisation, secure coding practices.
• Communication layer: Encrypted communications, certificate validation, protocol security.
• Update layer: Signed firmware updates, rollback protection, integrity verification.
• Monitoring layer: Audit logging, anomaly detection, CVD policy for external input.
• Process layer: SDLC, threat modelling, penetration testing, PSIRT.

A conformity assessment examines all these layers collectively — a product that excels in one area but has significant gaps in another does not satisfy the Annex I requirements.

A concrete defence-in-depth architecture for a connected IoT product might include:

Physical: Locked debug interfaces, tamper-evident enclosures. Boot: Secure Boot with hardware root of trust, rollback protection. OS: Read-only root filesystem, process isolation, AppArmor profiles, minimal installed packages. Network: Firewall denying all inbound connections except required services, TLS for all communications, certificate pinning for update server. Application: Input validation, authentication for all APIs, privilege separation between services. Update: Signed OTA updates, A/B partitioning, update server authentication. Monitoring: Syslog forwarding to operator SIEM, anomaly detection for abnormal network behaviour. Response: Published CVD policy with safe harbour, PSIRT process, CSAF advisory publication.

This layered architecture means an attacker exploiting a single application vulnerability cannot directly access the firmware update mechanism, and cannot bypass Secure Boot even if they achieve code execution.

The Annex VII technical file should document the product's defence-in-depth architecture to demonstrate to Notified Bodies and MSAs that the essential requirements are comprehensively addressed. Effective documentation approaches:

• Security architecture diagram: A visual representation of all security layers, showing how they interact and overlap.
• Control mapping: A table mapping each CRA Annex I essential requirement to the specific security controls that address it, showing which controls are primary and which are compensating.
• Residual risk register: For identified threats where the defence-in-depth architecture does not provide complete mitigation, document the residual risk and the risk acceptance rationale.
• Test coverage: For each security layer, reference the testing evidence that demonstrates the control is effective — pen test reports, code review findings, fuzzing results.