ENISA Security by Design and Default Playbook v0.4: 22 Principles Mapped to CRA Annex I (Developer Guide 2026)

Post #805 in the sota.io EU Compliance Series

In March 2026, ENISA published version 0.4 of its Security by Design and Default Playbook — a structured consultation draft providing 22 actionable principles for software developers, technical product managers, and SME security leads. The document is significant for one specific reason: Annex C maps every one of the 22 principles directly to CRA Annex I essential requirements, creating the clearest available bridge between security engineering practice and Cyber Resilience Act compliance obligation.

The CRA's December 2027 enforcement deadline is 19 months away. The ENISA Playbook v0.4 is currently in public consultation with final publication expected Q2/Q3 2026 — meaning the document you read today is close to its final form. Working through all 22 principles against your product architecture now gives you a structured head start on CRA Annex I conformity before market surveillance authorities begin enforcement.

This guide covers every principle, the CRA Annex I sections each maps to, a Python implementation for scoring your codebase, and a 25-item checklist for the December 2027 deadline.

What the ENISA Playbook v0.4 Covers

The Playbook is structured around two categories of principle:

• 14 Secure by Design principles — architectural and development lifecycle decisions that embed security from the earliest design phase
• 8 Secure by Default principles — configuration and deployment decisions that ensure products ship in a secure state without requiring users to reconfigure

Target audiences named by the Playbook are software developers, technical product managers, and SME security leads. The Playbook explicitly avoids being a theoretical framework — each principle includes a practical description, implementation guidance, and the CRA Annex I mapping.

Part I: 14 Secure by Design Principles

Principle SbD-1: Asset and Threat Identification

Before writing a line of code, identify the digital assets your product handles — data, credentials, keys, configuration — and the threat actors likely to target them. The Playbook specifies this as a prerequisite for all downstream security decisions.

CRA Mapping: CRA Annex I, Part I, §1 (security requirements for products with digital elements appropriate to the risks). Risk identification is the prerequisite for all Part I requirements.

Implementation: A threat model document (STRIDE, PASTA, or lightweight attack surface analysis) maintained as a living artifact throughout the development lifecycle. Not a one-time exercise.

Principle SbD-2: Secure Development Lifecycle (SDL)

Security activities must be embedded across the software development lifecycle — requirements, design, implementation, testing, deployment, and maintenance — not applied as a post-build audit.

CRA Mapping: CRA Annex I, Part I, §1 (design and development with appropriate security level), Art.13(1) (manufacturers shall take into account CRA requirements throughout lifecycle).

Implementation: Mandatory security review gates at: requirements sign-off, architecture review, code review, and before release tagging. Track gate outcomes in your issue tracker.

Principle SbD-3: Minimal Attack Surface

Expose only the interfaces, endpoints, protocols, and services required for legitimate functionality. Every unnecessary exposure is a potential vulnerability that must be patched indefinitely.

CRA Mapping: CRA Annex I, Part I, §2 (no more than necessary functionality, limiting attack surface). This is one of the most directly CRA-relevant principles.

Implementation: An interface inventory reviewed at every major release. Remove deprecated endpoints rather than leaving them dormant. Close unused ports and protocols in infrastructure configuration.

Principle SbD-4: Least Privilege

Every component, service, process, and user identity should operate with the minimum permissions required to perform its function. Privilege escalation paths should be explicit, audited, and rare.

CRA Mapping: CRA Annex I, Part I, §3 (limiting access to functions and data to what is necessary). Maps to access control requirements.

Implementation: Service accounts with scoped IAM roles. No shared admin credentials. Database users with read-only access unless write is explicitly required. Reviewed on every new service addition.

Principle SbD-5: Defense in Depth

No single security control should be the only barrier between an attacker and a critical asset. Layer multiple independent controls so that failure of one does not immediately compromise the system.

CRA Mapping: CRA Annex I, Part I, §1 (appropriate protection against unauthorised access), §4 (appropriate mechanisms to ensure the product can be updated, monitoring integrity).

Implementation: Network segmentation + authentication + authorization + encryption at rest + encryption in transit + audit logging as independent layers. Document the layering architecture.

Principle SbD-6: Security Architecture Documentation

The security architecture — trust boundaries, data flows, authentication mechanisms, key management — must be documented in sufficient detail for threat model updates and incident response.

CRA Mapping: CRA Art.13(4) (technical documentation), CRA Art.22(3) (technical file content including design information).

Implementation: An architecture diagram (C4 model or equivalent) showing trust boundaries. Updated when significant changes occur. Included in the CRA Technical File under Art.22.

Principle SbD-7: Cryptographic Agility

Cryptographic primitives age badly. Design your system so that algorithms, key sizes, and cryptographic libraries can be replaced without requiring a fundamental rearchitecture.

CRA Mapping: CRA Annex I, Part I, §1 (appropriate protection mechanisms), §5 (products shall protect the confidentiality of data at rest and in transit using state-of-the-art encryption). "State of the art" implies algorithmic currency.

Implementation: Parameterize cipher suites rather than hardcoding. Use cryptographic library abstractions (e.g., Python cryptography library) rather than raw algorithm calls. Track algorithm deprecation timelines (NIST, BSI, ENISA).

Principle SbD-8: Secure Input Validation

All input from external sources — users, APIs, files, environment variables, configuration — must be validated for type, format, range, and permitted values before processing.

CRA Mapping: CRA Annex I, Part I, §1 (protection against exploitation of vulnerabilities), §2 (no more than necessary processing of data reducing attack surface). Input injection is a primary vulnerability class the CRA aims to address.

Implementation: A validation layer at every trust boundary. Schema validation for structured inputs (JSON Schema, Pydantic, Zod). Parameterized queries. No string concatenation in SQL or shell contexts.

Principle SbD-9: Error Handling and Logging Security

Errors must not expose sensitive information — stack traces, internal paths, credentials, or system details — to external parties. Logging must capture security-relevant events without recording sensitive data in logs.

CRA Mapping: CRA Annex I, Part I, §1 (protection of confidentiality of data), §8 (logging of security-relevant events). Directly maps to the audit log requirement.

Implementation: Custom error pages that hide internal details. Structured logging with explicit sensitive-field exclusion lists. SIEM ingestion of security event logs with retention policy.

Principle SbD-10: Dependency and Supply Chain Security

Third-party components — libraries, frameworks, containers, cloud services — introduce risk that must be managed continuously. The supply chain is an attack surface.

CRA Mapping: CRA Annex I, Part II, §1 (vulnerability identification in components), §2 (SBOM requirement), CRA Art.13(5) (security updates for vulnerabilities in components).

Implementation: Software Bill of Materials (SBOM) in SPDX or CycloneDX format. Automated dependency scanning (Dependabot, Snyk, OSV Scanner). Pinned dependency versions with hash verification. Third-party component vetting process before adoption.

Principle SbD-11: Secure Configuration Management

Configuration — environment variables, feature flags, infrastructure parameters, secrets — must be managed securely. Secrets must never appear in code, logs, or version control.

CRA Mapping: CRA Annex I, Part I, §2 (default configuration security), §3 (access control for configuration).

Implementation: Secrets management system (Vault, AWS Secrets Manager, environment-isolated secrets). Configuration drift detection. Infrastructure-as-code with security configuration validated in CI.

Principle SbD-12: Security Testing Integration

Security testing — SAST, DAST, dependency scanning, fuzz testing — must be integrated into CI/CD pipelines and executed on every significant change.

CRA Mapping: CRA Art.13(1) (security throughout lifecycle), Annex I Part I §1 (appropriate security measures), Art.13(7) (security updates based on vulnerability identification).

Implementation: SAST in PR checks (CodeQL, Semgrep). DAST in pre-production environment. Dependency vulnerability gates that block deployment on critical CVEs. Fuzz testing for parsing-heavy components.

Principle SbD-13: Key and Certificate Management

Cryptographic keys and certificates must be generated securely, stored in hardware security modules or equivalent isolation, rotated on schedule, and revoked when compromised.

CRA Mapping: CRA Annex I, Part I, §5 (state-of-the-art encryption and key management), §3 (authentication and access control for key material).

Implementation: No hardcoded keys. HSM or equivalent for production key material. Automated certificate renewal (Let's Encrypt + cert-manager, or managed PKI). Documented key rotation procedure with calendar triggers.

Principle SbD-14: Incident Response Readiness

Security architecture must include provisions for detecting breaches, containing damage, preserving evidence, and notifying affected parties. CRA creates notification obligations triggered by active exploitation.

CRA Mapping: CRA Art.14 (actively exploited vulnerability reporting to ENISA and market surveillance within 24 hours), Art.13(6) (security updates addressing vulnerabilities), Annex I Part II §3 (vulnerability disclosure policy).

Implementation: Incident response runbook. SIEM or equivalent for detection. Evidence preservation (log archival, immutable audit trails). Documented ENISA notification procedure including the 24-hour timeline.

Part II: 8 Secure by Default Principles

Principle SbDef-1: Secure Initial Configuration

Products must ship with a secure configuration as the default state. Users should not need to "harden" a product before it is safe to deploy. Every default must be the most secure reasonable option.

CRA Mapping: CRA Annex I, Part I, §2 (products shall be delivered with a secure by default configuration, including the possibility to reset the product to its original state). This is one of the strongest direct CRA mandates.

Implementation: Audit every default setting against "what would an attacker exploit?" Change anything exploitable by default. Document your secure default configuration in technical documentation.

Principle SbDef-2: Minimal Default Functionality

Ship only the functionality required for the product's stated purpose. Optional features, administrative interfaces, and debugging tools must be disabled by default and explicitly enabled by users.

CRA Mapping: CRA Annex I, Part I, §2 (no more functionality than necessary by default). Directly addresses the attack surface reduction requirement.

Implementation: Feature flag audit for every release. Default-off for: remote debugging, verbose logging, admin APIs, telemetry, and experimental features. Document the enabling procedure in user documentation.

Principle SbDef-3: Authentication Required by Default

No functionality that accesses data or modifies state should be accessible without authentication by default. Anonymous access should be an explicit opt-in, not the default state.

CRA Mapping: CRA Annex I, Part I, §3 (appropriate authentication and access control mechanisms, restricting privileged access).

Implementation: Authentication middleware applied to all routes by default. An explicit allowlist for public routes. API keys or OAuth tokens required for all API access. Basic auth disabled except in explicitly defined contexts.

Principle SbDef-4: Encrypted Communications by Default

All communications between components — user to application, application to database, application to third-party API — must use encrypted transport by default. Plaintext should not be possible without explicit configuration.

CRA Mapping: CRA Annex I, Part I, §5 (state-of-the-art encryption for data in transit). The "by default" requirement is explicit in Part I §2.

Implementation: TLS 1.2+ enforced, 1.3 preferred. HTTP to HTTPS redirect with HSTS preloading. No plaintext inter-service communication. Certificate validation enforced (no verify=False).

Principle SbDef-5: Minimal Logging and Data Retention by Default

The default logging configuration should capture security-relevant events without capturing personal data or sensitive application data. Log retention should default to the minimum period required for security analysis.

CRA Mapping: CRA Annex I, Part I, §9 (data minimisation), GDPR Art.5(1)(e) (storage limitation) as a co-constraint. CRA and GDPR together define the design space.

Implementation: Structured log schema with explicit exclusion of PII fields. Default retention 30-90 days for access logs, 1 year for security event logs. Log scrubbing pipeline for any inadvertently captured sensitive data.

Principle SbDef-6: Automatic Security Updates by Default

Products should check for and notify users of security updates automatically by default. Where technically feasible, critical security updates should apply automatically without user intervention.

CRA Mapping: CRA Annex I, Part II, §5 (security updates distributed without delay, automatically where possible), CRA Art.13(3) (ensuring security updates are made available for the support period).

Implementation: Update notification mechanism in product UI or admin panel. Automatic security patch application for containerized deployments. Support period documented in technical file.

Principle SbDef-7: Privacy-Preserving Defaults

Products that handle personal data should process the minimum necessary by default — no opt-in tracking, no telemetry without consent, no third-party integrations that receive personal data without explicit user action.

CRA Mapping: CRA Annex I, Part I, §9 (data minimisation by default), GDPR Art.25 (data protection by design and by default) as the primary obligation for personal data.

Implementation: Telemetry disabled by default. Analytics behind user consent. Third-party scripts that set cookies blocked until consent. PII fields explicitly declared in data model and reviewed for necessity.

Principle SbDef-8: Failure Safe Defaults

When a security control fails — authentication service unavailable, certificate validation error, rate limiter crashed — the default behavior must be to deny access, not to fail open.

CRA Mapping: CRA Annex I, Part I, §1 (appropriate protection even under failure conditions), §4 (resilience against denial of service and other exploitation). Fail-safe is a component of availability and integrity.

Implementation: Circuit breakers configured to deny rather than permit on failure. Authentication middleware that returns 503 rather than bypassing auth when the auth service is down. Test failure scenarios explicitly in staging.

Annex C: CRA Annex I Mapping Summary

The ENISA Playbook Annex C provides a structured mapping. The table below consolidates the key correspondences:

Python Implementation: SecurityByDesignAudit

from dataclasses import dataclass, field
from typing import Optional
from datetime import date

@dataclass
class PrincipleAudit:
    principle_id: str
    name: str
    category: str  # "secure_by_design" | "secure_by_default"
    cra_annex_i_refs: list[str]
    implemented: bool = False
    implementation_notes: str = ""
    evidence_location: str = ""  # path to doc/code evidence
    last_reviewed: Optional[date] = None
    gap_description: str = ""

class SecurityByDesignAudit:
    def __init__(self, product_name: str):
        self.product_name = product_name
        self.principles: list[PrincipleAudit] = self._init_principles()
    
    def _init_principles(self) -> list[PrincipleAudit]:
        return [
            # Secure by Design
            PrincipleAudit("SbD-1", "Asset and Threat Identification", "secure_by_design",
                ["Annex I Part I §1"], gap_description="No threat model documented"),
            PrincipleAudit("SbD-2", "Secure Development Lifecycle", "secure_by_design",
                ["Annex I Part I §1", "Art.13(1)"], gap_description="No SDL gates in CI"),
            PrincipleAudit("SbD-3", "Minimal Attack Surface", "secure_by_design",
                ["Annex I Part I §2"], gap_description="No interface inventory"),
            PrincipleAudit("SbD-4", "Least Privilege", "secure_by_design",
                ["Annex I Part I §3"], gap_description="Service accounts not scoped"),
            PrincipleAudit("SbD-5", "Defense in Depth", "secure_by_design",
                ["Annex I Part I §1", "§4"], gap_description="No layering architecture documented"),
            PrincipleAudit("SbD-6", "Security Architecture Documentation", "secure_by_design",
                ["Art.13(4)", "Art.22(3)"], gap_description="Missing from technical file"),
            PrincipleAudit("SbD-7", "Cryptographic Agility", "secure_by_design",
                ["Annex I Part I §1", "§5"], gap_description="Hardcoded cipher suites"),
            PrincipleAudit("SbD-8", "Secure Input Validation", "secure_by_design",
                ["Annex I Part I §1", "§2"], gap_description="No schema validation at trust boundaries"),
            PrincipleAudit("SbD-9", "Error Handling and Logging Security", "secure_by_design",
                ["Annex I Part I §1", "§8"], gap_description="Stack traces exposed in errors"),
            PrincipleAudit("SbD-10", "Dependency and Supply Chain Security", "secure_by_design",
                ["Annex I Part II §1", "§2", "Art.13(5)"], gap_description="No SBOM generated"),
            PrincipleAudit("SbD-11", "Secure Configuration Management", "secure_by_design",
                ["Annex I Part I §2", "§3"], gap_description="Secrets in environment without rotation"),
            PrincipleAudit("SbD-12", "Security Testing Integration", "secure_by_design",
                ["Art.13(1)", "Annex I Part I §1"], gap_description="No SAST in CI"),
            PrincipleAudit("SbD-13", "Key and Certificate Management", "secure_by_design",
                ["Annex I Part I §5", "§3"], gap_description="No certificate renewal automation"),
            PrincipleAudit("SbD-14", "Incident Response Readiness", "secure_by_design",
                ["Art.14", "Art.13(6)", "Annex I Part II §3"], gap_description="No ENISA notification procedure documented"),
            # Secure by Default
            PrincipleAudit("SbDef-1", "Secure Initial Configuration", "secure_by_default",
                ["Annex I Part I §2"], gap_description="No default configuration audit done"),
            PrincipleAudit("SbDef-2", "Minimal Default Functionality", "secure_by_default",
                ["Annex I Part I §2"], gap_description="Debug interface enabled by default"),
            PrincipleAudit("SbDef-3", "Authentication Required by Default", "secure_by_default",
                ["Annex I Part I §3"], gap_description="Anonymous access not audited"),
            PrincipleAudit("SbDef-4", "Encrypted Communications by Default", "secure_by_default",
                ["Annex I Part I §5"], gap_description="No HSTS enforcement verified"),
            PrincipleAudit("SbDef-5", "Minimal Logging and Data Retention", "secure_by_default",
                ["Annex I Part I §9"], gap_description="No PII exclusion in log schema"),
            PrincipleAudit("SbDef-6", "Automatic Security Updates by Default", "secure_by_default",
                ["Annex I Part II §5", "Art.13(3)"], gap_description="No auto-update mechanism"),
            PrincipleAudit("SbDef-7", "Privacy-Preserving Defaults", "secure_by_default",
                ["Annex I Part I §9"], gap_description="Telemetry enabled by default"),
            PrincipleAudit("SbDef-8", "Failure Safe Defaults", "secure_by_default",
                ["Annex I Part I §1", "§4"], gap_description="Auth failure mode not tested"),
        ]
    
    def mark_implemented(self, principle_id: str, notes: str, evidence: str):
        p = next((p for p in self.principles if p.principle_id == principle_id), None)
        if p:
            p.implemented = True
            p.implementation_notes = notes
            p.evidence_location = evidence
            p.last_reviewed = date.today()
    
    def score(self) -> dict:
        total = len(self.principles)
        implemented = sum(1 for p in self.principles if p.implemented)
        sbd_total = sum(1 for p in self.principles if p.category == "secure_by_design")
        sbd_impl = sum(1 for p in self.principles if p.category == "secure_by_design" and p.implemented)
        sbdef_total = sum(1 for p in self.principles if p.category == "secure_by_default")
        sbdef_impl = sum(1 for p in self.principles if p.category == "secure_by_default" and p.implemented)
        return {
            "product": self.product_name,
            "overall_score": f"{implemented}/{total} ({100*implemented//total}%)",
            "secure_by_design": f"{sbd_impl}/{sbd_total}",
            "secure_by_default": f"{sbdef_impl}/{sbdef_total}",
            "gaps": [{"id": p.principle_id, "name": p.name, "gap": p.gap_description}
                     for p in self.principles if not p.implemented],
            "cra_readiness": "HIGH" if implemented/total >= 0.85 else
                             "MEDIUM" if implemented/total >= 0.6 else "LOW",
        }

# Usage
audit = SecurityByDesignAudit("MyEUSaaSProduct")

# Mark implemented principles with evidence
audit.mark_implemented("SbD-4", "Scoped IAM roles for all services", "docs/iam-policy-matrix.md")
audit.mark_implemented("SbD-8", "Pydantic validation on all API endpoints", "src/api/validators.py")
audit.mark_implemented("SbDef-4", "HSTS enforced via nginx, TLS 1.3", "infra/nginx.conf")
audit.mark_implemented("SbDef-1", "Default config audited Q1 2026", "docs/default-config-audit.md")

result = audit.score()
print(result)
# {'product': 'MyEUSaaSProduct', 'overall_score': '4/22 (18%)', 
#  'secure_by_design': '2/14', 'secure_by_default': '2/8',
#  'cra_readiness': 'LOW', 'gaps': [...20 gaps...]}

The CLOUD Act Infrastructure Problem for SbD-14

Principle SbD-14 — Incident Response Readiness — has a specific interaction with US-jurisdiction infrastructure that the ENISA Playbook does not address directly but that every EU developer using AWS, GCP, or Azure must account for.

CRA Art.14 requires notifying ENISA and market surveillance authorities of actively exploited vulnerabilities within 24 hours of awareness. This notification must include:

• The nature of the vulnerability
• The products affected
• Corrective action taken or planned
• Whether the vulnerability is already being exploited in the wild

A company operating on US infrastructure receives a CLOUD Act subpoena for forensic evidence during an active security incident. The subpoena may compel the cloud provider to produce log files, memory snapshots, or communications before the company has completed its own forensic analysis. The company may learn of the CLOUD Act disclosure only after it has occurred — affecting what it can lawfully disclose to ENISA and market surveillance authorities about the incident timeline and evidence state.

Operating on EU-sovereign infrastructure — with infrastructure providers subject exclusively to EU legal process — removes this jurisdictional interference from your incident response chain. The Art.14 24-hour notification clock runs the same regardless of infrastructure jurisdiction. The difference is whether a parallel legal process can complicate what you know and when you know it.

25-Item CRA Readiness Checklist (ENISA Playbook Mapped)

Use this checklist to validate your product against the 22 ENISA principles before the December 2027 CRA enforcement deadline:

Secure by Design — Architecture

• 1. Threat model created and maintained in version control (SbD-1)
• 2. SDL gates implemented at requirements, design, code review, release (SbD-2)
• 3. Interface inventory documented and reviewed each release (SbD-3)
• 4. Service accounts use scoped, minimal permissions — no shared admin credentials (SbD-4)
• 5. Security layering architecture documented (network + auth + authz + encryption + audit) (SbD-5)
• 6. Security architecture diagram in CRA Technical File (SbD-6)
• 7. Cipher suites parameterized — no hardcoded algorithm references (SbD-7)
• 8. Input validation at all trust boundaries — schema validation for structured inputs (SbD-8)
• 9. Error handling hides internal details — no stack traces or credential values in responses (SbD-9)

Secure by Design — Supply Chain and Operations

• 10. SBOM generated in SPDX or CycloneDX format (SbD-10, CRA Annex I Part II §2)
• 11. Automated dependency vulnerability scanning in CI — critical CVEs block release (SbD-10, SbD-12)
• 12. Secrets managed in dedicated secrets system — not in code, not in logs (SbD-11)
• 13. SAST and DAST integrated into CI/CD pipeline (SbD-12)
• 14. Certificate renewal automated — no manual renewal required for production certs (SbD-13)
• 15. ENISA 24-hour notification procedure documented and tested (SbD-14, CRA Art.14)

Secure by Default — Configuration

• 16. Default configuration audit completed — every default is the most secure reasonable option (SbDef-1)
• 17. Optional features, admin interfaces, and debug tools disabled by default (SbDef-2)
• 18. All routes authenticated by default — public routes in explicit allowlist (SbDef-3)
• 19. HTTPS enforced everywhere — HSTS enabled, TLS 1.2+ minimum (SbDef-4)

Secure by Default — Data and Updates

• 20. Log schema explicitly excludes PII fields — log scrubbing pipeline operational (SbDef-5)
• 21. Security update notification mechanism in product UI or admin panel (SbDef-6)
• 22. Support period documented in technical file — update commitment is enforceable (SbDef-6, CRA Art.13(3))
• 23. Telemetry and third-party analytics off by default — consent-gated (SbDef-7)
• 24. Authentication failure mode tested — service denies access when auth unavailable (SbDef-8)
• 25. Security architecture reviewed and updated against ENISA Playbook final publication (expected Q2/Q3 2026)

Deployment Infrastructure as a Security Principle

The ENISA Playbook focuses on product-level security decisions. One infrastructure-level decision the Playbook does not address — because it is in scope for other ENISA guidance documents — is the legal jurisdiction of your deployment infrastructure.

The CRA treats all products placed on the EU market uniformly regardless of where the manufacturer is domiciled or where the product's infrastructure runs. But the legal remedies available to EU authorities when investigating a security incident differ significantly between products running on EU-domiciled infrastructure versus products running on US-parent cloud providers.

sota.io is a EU-native PaaS built for developers who want to close this gap at the infrastructure layer — a deployment environment where the complete legal and operational stack is subject to EU jurisdiction. For the 25 ENISA principles above, the infrastructure layer is the foundation on which principles SbD-14 (incident response), SbD-9 (logging), and SbDef-5 (data minimisation) operate. Choosing EU-sovereign infrastructure is not a substitute for the 22 ENISA principles — it is the platform on which you implement them without a parallel US legal process running alongside your EU compliance obligations.

Timeline: ENISA Playbook and CRA Enforcement

The December 2027 deadline is not a cliff — it is when market surveillance authorities gain enforcement power. The ENISA Playbook v0.4 gives you 19 months to implement 22 principles with a Python scoring tool to track your gap closure. The 25-item checklist above is the minimum audit surface MSAs are likely to apply when assessing CRA Annex I conformity.

sota.io publishes practical developer guides on EU cybersecurity and data regulation. The Security by Design series covers CRA Art.13 manufacturer obligations, ENISA guidance documents, and technical implementation patterns for EU-sovereign software development.