ENISA Secure by Design Playbook 2026: 22 Principles Mapped to CRA Annex I for EU Developers

Post #830 in the sota.io EU Compliance Series

The Cyber Resilience Act (CRA) takes full effect in stages through 2026 and 2027. Products with digital elements placed on the EU market must satisfy the essential cybersecurity requirements in CRA Annex I. ENISA — the EU's cybersecurity agency — has published Secure by Design guidance that translates those requirements into actionable engineering principles.

The result is a set of 22 principles that map directly onto CRA Annex I Part I (essential product requirements) and Part II (vulnerability handling requirements). For EU software teams, understanding this mapping is the difference between a compliance programme built on guesswork and one built on a repeatable engineering framework.

This guide walks through all 22 principles, their CRA Annex I mapping, what each means concretely for your codebase, and where EU-native infrastructure removes obligations that US-hosted deployments cannot satisfy.

Why Secure by Design Matters for CRA

CRA Annex I Part I, paragraph 1 opens with the obligation that products "shall be designed, developed and produced in such a way as to ensure an appropriate level of cybersecurity based on the risks." This is not a checklist tick — it is a process requirement. You must be able to demonstrate that security was built in from the design phase, not bolted on after.

ENISA's Secure by Design framework provides the documented process that satisfies this obligation. National market surveillance authorities auditing CRA compliance will look for evidence of design-phase security decisions. ENISA's 22 principles are the vocabulary of that evidence.

Part I: Product Essential Requirements — Design Principles 1–13

CRA Annex I Part I lists the essential cybersecurity properties that all products with digital elements must demonstrate. The following principles map to specific Annex I Part I requirements.

Principle 1 — Minimise Attack Surface

CRA Annex I Part I mapping: Requirement to "not be placed on the market with known exploitable vulnerabilities" and to "have a minimal attack surface."

Every interface, port, protocol, library, and service that your product exposes is potential attack surface. Attack surface minimisation means systematically eliminating exposure that is not necessary for the product's function. Unused ports closed. Unused API endpoints removed or disabled by default. Third-party dependencies audited and pruned. Internal services not externally exposed.

For EU SaaS products: if your product runs on a shared US-hosted platform, the attack surface includes the platform provider's control plane — and any US legal process served on that provider can reach your deployment. EU-native infrastructure with dedicated isolation (no shared tenant control planes) reduces this structural attack surface.

Practical implementation:

• Map every external interface during design review
• Require documented justification for each exposed interface
• Run automated port scanning as part of CI/CD
• Quarterly dependency audits removing packages unused in the last two major versions

Principle 2 — Establish Secure Defaults

CRA Annex I Part I mapping: Requirement to be "delivered with a secure default configuration, including the possibility to reset the product to its original state."

Secure defaults mean that a developer who deploys your product without reading the security documentation arrives at a secure state. Authentication enabled. Unnecessary features disabled. Verbose error messages suppressed. Admin interfaces accessible only from designated networks.

CRA enforcement will scrutinise default configurations. An auditor who can access an admin panel without credentials in a default deployment will trigger a finding regardless of what the security documentation says about disabling it.

Practical implementation:

• Review all configuration defaults in each release
• Run integration tests with a clean default deployment and verify security properties
• Document explicitly: what is disabled by default and what steps are required to enable it

Principle 3 — Apply Least Privilege

CRA Annex I Part I mapping: Requirement that products "protect the confidentiality, integrity and availability of data" and "restrict access control."

Every component, service, and user in your system should operate with the minimum permissions required to perform its function. Database service accounts with read-only access to the tables they query. Lambda functions with IAM policies scoped to the specific S3 bucket they write. Service-to-service calls authenticated and authorised to the specific operations required.

Overprivileged services are the primary reason that single-component compromises escalate to full data breaches. CRA Annex I requires that you limit the blast radius of incidents — and least privilege is the engineering mechanism for doing so.

Practical implementation:

• Maintain an inventory of all service identities and their permission sets
• Review permissions quarterly against actual usage (cloud providers expose last-used timestamps)
• Reject pull requests that grant wildcard permissions without documented justification

Principle 4 — Apply Defence in Depth

CRA Annex I Part I mapping: Requirement to "limit the impact on other services or devices" and protect availability.

No single security control is sufficient. Defence in depth requires layered controls such that the failure or bypass of any single layer does not result in a breach. Network controls (firewall rules, VPC isolation), application controls (input validation, authentication), data controls (encryption, access logs), and operational controls (alerting, response playbooks) must all be present and independent.

Practical implementation:

• Threat model each feature with explicit consideration of what happens when each control fails
• Test each layer independently — do not rely on outer layers to compensate for inner layer weaknesses
• Document which controls are compensating for which risks

Principle 5 — Fail Securely

CRA Annex I Part I mapping: Requirement to "protect the availability and integrity of data" and prevent unintended data exposure.

When your product encounters an error condition — network timeout, unexpected input, hardware failure, dependency unavailability — it must fail in a state that does not expose sensitive data, grant unintended access, or corrupt data. A failed authentication attempt should return a generic error, not a stack trace. A failed database transaction should roll back completely, not persist partial state.

Practical implementation:

• Review error handlers explicitly for information leakage
• Test failure paths — not just happy paths — in integration testing
• Use structured logging that captures error context without embedding PII or credentials

Principle 6 — Protect Data at Rest and in Transit

CRA Annex I Part I mapping: Requirement to "protect the confidentiality of data, for instance by encrypting relevant data at rest and in transit."

All sensitive data must be encrypted at rest with keys managed outside the data store. All data in transit must use current TLS versions (TLS 1.2 minimum, TLS 1.3 preferred) with valid certificates from trusted CAs. This is stated explicitly in CRA Annex I and leaves no room for interpretation.

For EU developers using US-hosted infrastructure: encryption at rest does not protect against compelled disclosure under the US CLOUD Act. The encryption keys are managed by or accessible to the US-jurisdiction provider. Genuine confidentiality protection requires infrastructure where the key management system itself is outside US legal reach.

Practical implementation:

• Enforce TLS 1.2+ in all service configuration and reject downgrade attempts
• Use envelope encryption with customer-managed keys where GDPR Art.32 requires it
• Document key management procedures and test recovery scenarios annually

Principle 7 — Minimise and Control Third-Party Dependencies

CRA Annex I Part I mapping: Requirement that products be delivered "without known exploitable vulnerabilities," covering the entire supply chain.

Every third-party dependency is a potential vulnerability source. CRA Annex I requires that you address vulnerabilities — including those inherited from dependencies — through security updates distributed without delay. Dependency management is therefore not optional maintenance: it is a CRA essential requirement.

Practical implementation:

• Maintain a software bill of materials (SBOM) in CycloneDX or SPDX format (CRA Part II requires this explicitly)
• Use automated vulnerability scanning (Dependabot, Trivy, Grype) in CI/CD
• Define a policy for how quickly critical dependency vulnerabilities must be resolved (CRA expects "without undue delay")

Principle 8 — Implement Strong Authentication

CRA Annex I Part I mapping: Requirement to "protect against unauthorized access" through access control.

Authentication is the gateway to access control. CRA Annex I requires that products restrict access to authorised users and services. Weak authentication — default credentials, weak password policies, no MFA for admin access — directly violates this requirement.

Practical implementation:

• Enforce MFA for all administrative access paths
• Use password policies that require length over complexity (NIST SP 800-63B guidance)
• Implement account lockout or exponential backoff for repeated authentication failures
• Audit authentication events and retain logs for the period required by your GDPR Record of Processing

Principle 9 — Implement Access Control

CRA Annex I Part I mapping: Requirement to "limit the blast radius" of security incidents and restrict access to what is necessary.

Authentication establishes identity. Access control determines what authenticated identities may do. Both are required. Role-based access control (RBAC) or attribute-based access control (ABAC) must be implemented consistently across all interfaces — not only the user-facing frontend but also API endpoints, administrative interfaces, and internal service calls.

Practical implementation:

• Enforce authorisation checks at the service layer, not only at the API gateway
• Test authorisation boundaries explicitly: authenticated user A should not be able to access user B's data
• Log all authorisation failures for security monitoring

Principle 10 — Protect Against Injection Attacks

CRA Annex I Part I mapping: Requirement that products be protected against "common vulnerabilities" as referenced in CRA recitals and ENISA guidance.

SQL injection, command injection, LDAP injection, and cross-site scripting (XSS) remain the most common categories of exploitable vulnerability in web-facing software. CRA Annex I requires that products not be placed on the market with known exploitable vulnerabilities — and these vulnerability classes are well-known, well-documented, and have known mitigations.

Practical implementation:

• Use parameterised queries exclusively for all database access — no string concatenation in SQL
• Validate and sanitise all inputs at the boundary (do not rely on client-side validation)
• Use Content Security Policy headers to limit XSS blast radius
• Run SAST tools (Semgrep, CodeQL) in CI/CD configured for OWASP Top 10 rules

Principle 11 — Implement Secure Logging and Monitoring

CRA Annex I Part I mapping: Requirement to "record and/or monitor relevant internal activity, including access to or modification of data, services or functions."

CRA Annex I explicitly requires audit logging capability. Logs must capture who accessed what data, when, and what operations were performed. This overlaps with GDPR Art.30 records of processing activity and Art.32 security measures, but CRA adds the specific product-level requirement that the logging capability be built into the product, not just implemented in operations.

Practical implementation:

• Log authentication events, authorisation decisions, and data access operations
• Use structured logging formats (JSON) that are machine-parseable for SIEM integration
• Store logs outside the primary application environment to prevent tampering
• Define retention periods that satisfy both GDPR data minimisation and CRA audit requirements

Principle 12 — Implement Secure Error Handling

CRA Annex I Part I mapping: Intersects with the prohibition on "known exploitable vulnerabilities" — verbose error messages are themselves exploitable information.

Error messages visible to end users must not expose stack traces, database schemas, internal service addresses, or other information that assists attackers. Error messages in logs must capture enough context for debugging without embedding PII, credentials, or secrets.

Practical implementation:

• Implement a global error handler that returns generic messages to users and structured context to logs
• Scan log output in test environments for accidentally logged secrets (detect-secrets, truffleHog)
• Review error handling in CI/CD — fail builds that log credentials or PII

Principle 13 — Protect Availability

CRA Annex I Part I mapping: Requirement to "protect the availability and integrity of data and services."

Availability protection includes rate limiting to prevent abuse, graceful degradation under load, and resilient architecture that prevents single component failure from cascading to full service unavailability. For products where availability is safety-critical (medical devices, industrial control systems), additional requirements apply — but for SaaS products, the baseline CRA requirement is that availability protection mechanisms exist.

Practical implementation:

• Implement rate limiting at the API gateway layer
• Use circuit breakers for dependencies to prevent cascading failures
• Test failure scenarios (chaos engineering for production-grade products)
• Document your availability SLA and the technical controls that enforce it

Part II: Vulnerability Handling Requirements — Principles 14–22

CRA Annex I Part II governs how products handle vulnerabilities once discovered. These are distinct from the product design requirements in Part I.

Principle 14 — Identify and Document Vulnerabilities

CRA Annex I Part II mapping: Requirement to "identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials."

SBOM generation is now a legal requirement under CRA for products placed on the EU market. The SBOM must be in a machine-readable format (CycloneDX JSON or SPDX RDFXML are the ENISA-recommended formats). It must document all components — including open source libraries — at a granularity sufficient to identify affected components when a vulnerability is disclosed.

Practical implementation:

• Integrate SBOM generation into your build pipeline (Syft, cdxgen, or build-tool native plugins)
• Store SBOMs with each release artifact and in your vulnerability management system
• Configure your vulnerability scanner to consume your SBOM and match against CVE databases

Principle 15 — Address Vulnerabilities Without Delay

CRA Annex I Part II mapping: Requirement to "address and remediate vulnerabilities without undue delay."

CRA does not define a specific SLA for vulnerability remediation, but "without undue delay" is interpreted by ENISA guidance as:

• Critical vulnerabilities (CVSS 9.0+): 24–72 hours for mitigating action
• High vulnerabilities (CVSS 7.0–8.9): 7–14 days
• Medium/Low: 30–90 days with documented risk acceptance

You must be able to document that you learned of each vulnerability and the timeline from discovery to remediation or documented risk acceptance.

Practical implementation:

• Set up automated alerts from your dependency scanner for new CVEs affecting your dependencies
• Define and document your vulnerability SLAs in a security policy
• Track vulnerability remediation in your issue tracker with discovery date and resolution date recorded

Principle 16 — Provide Security Updates

CRA Annex I Part II mapping: Requirement to "make security updates available to users and ensure they can be installed by users."

Security updates must be distributed to users without delay after the vulnerability is addressed. For SaaS products where updates are applied server-side, this is straightforward — but your deployment process must ensure updates are applied to user-facing production systems, not just released to a package registry.

Practical implementation:

• Define and document your patch deployment timeline (aim for ≤48 hours for critical patches)
• Test security patches in staging before production deployment, but do not let staging testing delay production deployment beyond your SLA
• Notify users of security updates through release notes or a security advisory mechanism

Principle 17 — Implement Coordinated Vulnerability Disclosure

CRA Annex I Part II mapping: Requirement to "put in place and enforce a policy on coordinated vulnerability disclosure."

CRA requires a coordinated vulnerability disclosure (CVD) policy — meaning that when someone reports a vulnerability in your product, you have a defined process for receiving, triaging, fixing, and disclosing it. The CVD policy must be publicly accessible.

ENISA's guidance points to ISO/IEC 29147 as the reference standard for CVD policy structure.

Practical implementation:

• Publish a security.txt file at your domain following RFC 9116 (https://yourproduct.com/.well-known/security.txt)
• Include a security contact email, PGP key, preferred reporting language, and policy URL
• Define and publish a CVD policy covering: what you consider in-scope, your response timelines, your safe harbour commitment to researchers who follow the policy

Principle 18 — Report Actively Exploited Vulnerabilities to ENISA

CRA Annex I Part II mapping: Requirement to "report to ENISA any actively exploited vulnerability contained in the product."

This is one of the more operationally demanding CRA requirements. Within 24 hours of discovering that a vulnerability in your product is being actively exploited in the wild, you must notify ENISA via the Single Reporting Platform. Within 72 hours, you must submit an early warning. Within 14 days, a final report.

For most SaaS products, this obligation will be rare — but the process must exist before you need it.

Practical implementation:

• Subscribe to threat intelligence feeds (CISA KEV, ENISA advisories) to identify active exploitation trends relevant to your stack
• Establish internal escalation procedures: who is responsible for ENISA reporting, what is the 24-hour decision process
• Test the notification process annually in a tabletop exercise

Principle 19 — Provide a Vulnerability Contact Point

CRA Annex I Part II mapping: Requirement to "provide a single point of contact for the reporting of vulnerabilities."

Users, researchers, and authorities must be able to reach you to report vulnerabilities. This contact point must be publicly accessible and maintained for the entire supported lifetime of the product.

Practical implementation:

• Create a security@ email address dedicated to vulnerability reports
• Reference this address in your security.txt file, privacy policy, and product documentation
• Ensure the address is monitored with a defined response SLA (ENISA guidance: acknowledge within 3 business days)

Principle 20 — Maintain Secure Update Mechanisms

CRA Annex I Part II mapping: Requirement to "ensure that security updates are distributed in a timely manner and, where technically feasible, automatically."

The update mechanism itself must be secure. Software updates delivered over insecure channels, with unsigned packages, or without integrity verification create a supply chain attack vector. CRA requires that the mechanism for distributing security updates is protected against tampering.

Practical implementation:

• Sign all release artifacts (packages, container images) with verified developer keys
• Verify signatures in deployment pipelines before applying updates
• Use HTTPS with certificate pinning for update checks where applicable
• Document your update mechanism in product security documentation

Principle 21 — Maintain Software Bill of Materials

CRA Annex I Part II mapping: Explicit requirement to draw up and maintain a software bill of materials.

The SBOM obligation under CRA Part II is separate from the inventory discipline described in Principle 14. CRA requires that the SBOM be available to market surveillance authorities on request. For enterprise SaaS products, customers may also contractually require SBOM access as part of their own supply chain due diligence.

Practical implementation:

• Generate SBOMs at build time and store them linked to each release
• Use a consistent format: CycloneDX 1.4+ JSON is the most widely supported for machine analysis
• Make SBOMs available to enterprise customers on request as a standard security deliverable
• Update SBOMs when dependencies are updated — a stale SBOM is worse than no SBOM for audit purposes

Principle 22 — Disclose End-of-Life Security Status

CRA Annex I Part II mapping: Requirement to "provide security support for products placed on the EU market, including information on end-of-life."

When a product or product version reaches end of life, users must be notified of: when security support ends, what the migration path is, and what risks they accept by continuing to use an unsupported version. Silently abandoning product versions that remain in production violates CRA Part II.

Practical implementation:

• Publish a supported versions matrix in your product documentation
• Define a minimum support window (ENISA guidance suggests at least 5 years for many product categories)
• Send advance notice of end-of-life dates to affected users with a minimum 12-month warning period

CRA Annex I: Quick Reference Mapping Table

Where EU-Native Infrastructure Reduces Your CRA Obligation

Several of the 22 principles create obligations that are structurally harder to satisfy on US-hosted infrastructure:

Principle 6 (encryption): Encryption at rest using keys managed by a US-jurisdiction provider does not protect against compelled disclosure under the US CLOUD Act. Genuine key isolation requires infrastructure where neither the provider nor US authorities can access your encryption keys without EU legal process. EU-native providers with EU-jurisdiction key management satisfy this; US hyperscalers operating EU regions do not.

Principle 1 (attack surface): Shared control planes, shared tenant infrastructure, and US-operated global services all expand the attack surface beyond your direct control. Dedicated EU-native infrastructure with isolated control planes removes this structural exposure.

Principle 18 (ENISA reporting): If you are running on US infrastructure and discover active exploitation of your product, you have two concurrent notification obligations: ENISA (within 24 hours under CRA) and potentially your US-jurisdiction infrastructure provider's incident response process. These processes may conflict in timing and disclosure requirements.

EU-native hosting removes the jurisdictional conflict and allows you to document a clean line between your product's infrastructure and any US-law access obligations.

Getting Started: A Prioritised CRA Annex I Implementation Order

If you are starting a CRA compliance programme today, ENISA's guidance suggests this prioritisation based on enforcement risk and implementation effort:

Phase 1 (Month 1–2): Foundation

• Implement an SBOM pipeline (Principle 21)
• Publish a security.txt with vulnerability contact (Principle 19)
• Draft a coordinated vulnerability disclosure policy (Principle 17)
• Audit and document your default configuration (Principle 2)

Phase 2 (Month 3–4): Engineering Controls

• Conduct attack surface mapping and document reduction actions (Principle 1)
• Implement or audit authentication and access control (Principles 8, 9)
• Run SAST/DAST against injection attack classes (Principle 10)
• Implement structured logging with audit trail (Principle 11)

Phase 3 (Month 5–6): Vulnerability Operations

• Define vulnerability SLAs and enforcement process (Principle 15)
• Set up ENISA notification procedures (Principle 18)
• Define and publish end-of-life policy (Principle 22)
• Run first SBOM-against-CVE scan and address findings (Principle 14)

CRA's phased enforcement means market surveillance activities intensify through 2027. Products placed on the EU market from August 2025 are already subject to CRA obligations for manufacturers. Starting the 22-principle programme now gives EU SaaS teams a 12–18 month runway before active enforcement pressure.

sota.io deploys on EU-only infrastructure with no US parent company — ensuring that your hosting environment itself does not introduce CRA-incompatible jurisdictional exposure. Explore EU-native deployment →