sota.io
2026-05-28·5 min read·sota.io Team

ENISA Secure by Design Playbook 2026: The SaaS Developer's CRA Implementation Guide

Post #1 in the sota.io EU ENISA Secure by Design Series

ENISA Secure by Design Playbook 2026 — layered CRA compliance architecture for SaaS developers

The EU Cyber Resilience Act (CRA) enters full application in September 2026. At its core is a deceptively simple mandate: products with digital elements must be shipped secure by design. That phrase appears 7 times in the CRA text — and the European Union Agency for Cybersecurity (ENISA) has spent the past two years turning it into something actionable.

This post walks through ENISA's Secure by Design (SbD) framework as it applies to SaaS developers building products for the EU market. We cover the underlying principles, map them to CRA Annex I essential requirements, and give you a concrete 22-checkpoint implementation guide you can start on today.

If you're deploying on US-owned infrastructure, there's a layer of complexity in the tooling section you'll want to read — because the same CLOUD Act exposure that makes US PaaS risky for data also extends to your DevSecOps pipeline.

Why Secure by Design Is Not Optional

The CRA's essential cybersecurity requirements (Annex I, Part I) are not best-practice recommendations. They are mandatory conformity requirements. Products placed on the EU market that fail them can be:

The CRA's Article 12 on "security by design" requires manufacturers to:

  1. Design, develop, and produce products with no known exploitable vulnerabilities
  2. Implement security by default configurations
  3. Minimize attack surfaces
  4. Apply least-privilege principles to system design
  5. Ensure data minimization and encryption of stored/transmitted data

ENISA's role under the CRA is to develop technical guidance that translates these legal requirements into engineering practice. The SbD Playbook is that translation layer.

The ENISA Secure by Design Framework: Five Core Pillars

ENISA structures its SbD guidance around five interconnected security engineering principles. These predate the CRA but have been updated to align precisely with CRA Annex I requirements.

Pillar 1: Minimized Attack Surface

What it means: Every interface, feature, protocol, and credential that is not strictly necessary should not exist. Attack surface is proportional to exploitable opportunity.

CRA mapping: Art.12(3)(a) — "minimize the attack surface"

Practical implications for SaaS:

A common failure pattern: a SaaS product ships with a /debug/info endpoint that returns environment variables, dependency versions, and internal service topology. That endpoint is never documented. It's also never secured. ENISA SbD requires a deliberate decision for every exposed interface.

Pillar 2: Defense in Depth

What it means: No single security control is assumed to be perfect. Controls are layered so that the failure of one does not result in a breach.

CRA mapping: Art.12(1) — products "shall be delivered without any known exploitable vulnerabilities" — which implicitly requires that the absence of a vulnerability patch doesn't create total exposure.

Practical implications for SaaS:

The threat model here is adversarial: if an attacker bypasses your WAF rules, what stops them at the application layer? If they steal a service account token, what prevents lateral movement?

Pillar 3: Least Privilege

What it means: Every component, user, service, and process should have exactly the permissions required to perform its function — no more.

CRA mapping: Art.12(3)(b) — "limit access rights on a need-to-know basis"

Practical implications for SaaS:

The ENISA playbook specifically calls out IAM misconfigurations as the leading cause of cloud breaches covered by CRA-relevant incidents. Most SaaS developers think about least privilege for user roles. ENISA extends this explicitly to machine identities, service accounts, CI/CD systems, and infrastructure automation.

Pillar 4: Fail-Safe Defaults

What it means: When in doubt, systems should fail toward security, not functionality. Default configurations should be the most secure configuration.

CRA mapping: Art.12(2) — "ensure that security is provided by default"

Practical implications for SaaS:

The fail-safe principle also applies to error handling: when a security check fails (rate limiter throws, auth service times out), the default response must be deny, not allow. This is a common SaaS bug — "if auth service is unreachable, pass the request through."

Pillar 5: Open Security Standards

What it means: Security should rely on published, peer-reviewed cryptographic primitives and protocols — not proprietary implementations.

CRA mapping: Art.12(3)(c) — "use the most secure communications protocols that are state of the art"

Practical implications for SaaS:

CRA Annex I Mapping: From Legal Text to Engineering Checklist

The following table maps CRA Annex I, Part I essential requirements to ENISA SbD pillars and concrete engineering controls.

CRA RequirementENISA SbD PillarEngineering Control
Art.12(1): No known exploitable vulnerabilitiesAll pillarsAutomated SAST/DAST in CI; SCA for dependencies; patch cadence SLA
Art.12(2)(a): Secure by defaultFail-Safe DefaultsSecurity-first defaults in all config; opt-in for less-secure modes
Art.12(2)(b): No unnecessary attack surfaceMinimized Attack SurfaceInterface inventory; disabled-by-default features; port hardening
Art.12(3)(a): Minimize attack surfaceMinimized Attack SurfaceAutomated surface scan; API inventory; unused-service removal
Art.12(3)(b): Access controlLeast PrivilegeRBAC for all resources; MFA for admin access; service account scoping
Art.12(3)(c): Strong cryptographyOpen Security StandardsTLS 1.3; modern hash algos; key rotation; no deprecated primitives
Art.12(3)(d): Data protectionDefense in DepthEncryption at rest + transit; data minimization; pseudonymization
Art.12(3)(e): Supply chainDefense in DepthSBOM generation; dependency pinning; vendor security attestation
Art.12(4): Security updatesFail-Safe DefaultsAuto-update mechanism; 24h critical patch SLA; CVE monitoring
Art.12(5): Monitoring & loggingDefense in DepthSecurity event logging; tamper-resistant log storage; anomaly alerts
Art.13(1): Vulnerability disclosureOpen Security StandardsCVD policy; security.txt; responsible disclosure workflow
Art.14(1): Active exploitation reportingDefense in Depth24h ENISA/NCA notification; SBOM tracking; patch deployment proof

The 22-Checkpoint ENISA SbD Implementation Guide

ENISA organizes its SbD implementation guidance into four phases. The following 22 checkpoints are drawn from ENISA's technical guidance documents and mapped to CRA compliance timelines.

Phase 1: Architecture & Design (Checkpoints 1-7)

Checkpoint 1 — Threat Model Exists

Checkpoint 2 — Attack Surface Inventory

Checkpoint 3 — Trust Boundaries Documented

Checkpoint 4 — Cryptographic Standards Defined

Checkpoint 5 — Authentication Architecture Reviewed

Checkpoint 6 — Authorization Model Defined

Checkpoint 7 — Secrets Architecture Defined

Phase 2: Development & Pipeline (Checkpoints 8-14)

Checkpoint 8 — SAST Integrated in CI

Checkpoint 9 — SCA/SBOM in Pipeline

Checkpoint 10 — Secret Scanning

Checkpoint 11 — Dependency Pinning

Checkpoint 12 — Container Image Hardening

Checkpoint 13 — Security-Focused Code Review

Checkpoint 14 — Dependency License Compliance

Phase 3: Deployment & Infrastructure (Checkpoints 15-18)

Checkpoint 15 — Infrastructure Hardening

Checkpoint 16 — Runtime Protection

Checkpoint 17 — Secrets Injection (Not Environment Variables)

Checkpoint 18 — Immutable Infrastructure

Phase 4: Operations & Monitoring (Checkpoints 19-22)

Checkpoint 19 — Security Event Logging

Checkpoint 20 — Vulnerability Management Process

Checkpoint 21 — Incident Response Plan

Checkpoint 22 — Coordinated Vulnerability Disclosure Policy

SaaS-Specific Implementation Priorities

The 22-checkpoint framework applies to all digital products, but SaaS architectures have specific risk patterns that ENISA's guidance addresses with particular emphasis.

Multi-Tenancy Isolation

SaaS products serve multiple tenants from a shared infrastructure. ENISA SbD treats tenant isolation as a first-class security requirement, not a feature:

The most common multi-tenancy security failure is horizontal privilege escalation: GET /api/data?tenant_id=attacker_tenant_id returning another tenant's data because the API only checks if the user is authenticated, not if they belong to the specified tenant.

API Security at Scale

SaaS products expose large API surfaces. The ENISA SbD framework prioritizes:

# ENISA SbD principle: Fail-safe defaults in API authorization
# Wrong: implicit allow
def get_resource(resource_id: str, user: User) -> Resource:
    resource = db.get(resource_id)
    return resource  # No authorization check!

# Wrong: authorization bypass on error
def get_resource(resource_id: str, user: User) -> Resource:
    try:
        authorize(user, resource_id)
    except AuthServiceTimeout:
        pass  # Fail open on service unavailability
    return db.get(resource_id)

# Right: explicit deny, fail-safe on error
def get_resource(resource_id: str, user: User) -> Resource:
    if not authorize(user, resource_id):  # Explicit check
        raise PermissionDenied()
    return db.get(resource_id)

# authorize() must raise/return False on any failure
def authorize(user: User, resource_id: str) -> bool:
    try:
        result = auth_service.check(user.id, resource_id)
        return result.allowed
    except AuthServiceError:
        return False  # Fail closed on any error

Dependency Risk in SaaS Pipelines

SaaS products typically have 200-800 direct and transitive dependencies. ENISA's SbD framework treats the supply chain as a security boundary:

Risk CategoryENISA RecommendationCRA Article
Malicious packagesRegistry integrity checks; pinned checksumsArt.12(3)(e)
Vulnerable packagesSCA in CI; 24h critical patch SLAArt.14(1)
Abandoned packagesMaintainer health score; forking policyArt.12(1)
License violationsLicense scanning in CI; legal review processArt.13(3)
TyposquattingNamespace monitoring; private registry mirroringArt.12(3)(e)

The SBOM requirement (Art.13(6) for Class I products, voluntary for others) creates a useful forcing function: if you cannot enumerate your dependencies, you cannot assess their vulnerabilities. ENISA recommends producing SBOM as a CI artifact regardless of product class.

The EU-Sovereign Tooling Problem

Here is a practical problem that ENISA's SbD guidance doesn't resolve but that SaaS developers on US platforms face immediately:

Many of the tools used to implement SbD are themselves US-headquartered and subject to CLOUD Act.

Consider the typical DevSecOps stack:

ToolVendor HQCLOUD Act Risk
SnykUS (New York)Yes — source code and dependency data
VeracodeUS (Burlington, MA)Yes — source code and scan results
CheckmarxUS (New Jersey)Yes — source code and SAST results
GitHub Advanced SecurityUS (San Francisco)Yes — source code and vulnerability findings
Datadog SecurityUS (New York)Yes — runtime security events and logs
PagerDutyUS (San Francisco)Yes — incident and alert data
SentinelOneUS (Mountain View)Yes — endpoint/runtime protection data

ENISA's guidance acknowledges this tension in its discussions of supply chain security: the tools that protect your software supply chain are themselves part of your supply chain.

For EU-sovereign implementations:

# EU-Sovereign DevSecOps Stack (ENISA SbD Aligned)

SAST:
  - Semgrep (self-hosted, AGPL) — EU deployment, no external data transmission
  - CodeQL (GitHub Actions, EU datacenter region if using GitHub.com/EU)
  - SonarQube Community Edition (self-hosted, LGPL)

SCA/SBOM:
  - Syft (Anchore, OSS, self-hosted) — SBOM generation
  - Grype (Anchore, OSS, self-hosted) — vulnerability matching
  - Trivy (Aqua Security, OSS, self-hosted) — container + code scanning

Secrets Scanning:
  - detect-secrets (Yelp, OSS, pre-commit hook)
  - gitleaks (OSS, self-hosted CI action)

Secrets Management:
  - HashiCorp Vault (Budibase/Exoscale/OVHcloud managed offering)
  - Infisical (EU-deployable OSS, Infisical Cloud EU region)

Runtime Protection:
  - Falco (CNCF, self-hosted) — Kubernetes runtime security
  - Wazuh (Wazuh Inc., Spain-HQ, EU-deployable) — SIEM + intrusion detection

Vulnerability Management:
  - OpenVAS (Greenbone AG, Germany) — network scanning
  - DefectDojo (OSS, self-hosted) — vulnerability tracking

Container Registry:
  - Harbor (CNCF, self-hosted on EU infrastructure)
  - Gitea Container Registry (Germany-hosted Gitea instance)

The key principle: the security tools themselves should not transmit your source code, runtime data, or vulnerability findings to US jurisdictions. Under CLOUD Act, a US government subpoena to a US-headquartered security vendor can require disclosure of your security scan results, vulnerability findings, and potentially source code — without prior notification and without EU legal recourse.

This is not a theoretical risk. Several EU companies have discovered their "security tooling vendor" was the weak link in GDPR compliance audits.

CRA Timeline: What SbD Means for Your September 2026 Deadline

The CRA applies in stages:

DateCRA RequirementWhat You Must Have
August 2025 (Live)Art.14 — Active exploitation reportingProcess to notify ENISA/NCA within 24h of discovered exploitation
September 2026Full CRA applicationAll Annex I, Part I essential requirements (the 22 checkpoints above)
September 2026Annex I, Part II: vulnerability handlingCVD policy, SBOM, update mechanism, user notifications

Critical path for September 2026:

If you're starting now (May 2026), you have 16 weeks to full CRA application. The ENISA SbD framework suggests a phased approach:

Weeks 1-4 (May-June 2026): Architecture hardening

Weeks 5-8 (June-July 2026): Pipeline security

Weeks 9-12 (July-August 2026): Infrastructure and deployment

Weeks 13-16 (August-September 2026): Operations

Quick-Start: The SbD Minimum Viable Compliance Checklist

If you have limited time before September 2026, prioritize these 10 controls — they represent the highest-impact CRA compliance actions with the fastest implementation path:

  1. SBOM generation in CI — syft . -o spdx-json > sbom.json in every release pipeline (Art.13(6) requirement for Class I)
  2. CVD policy + security.txt — Publish /.well-known/security.txt with contact, PGP key, and response SLA (Art.13(6))
  3. SCA in CI — grype sbom:./sbom.json in CI, block on Critical/High (Art.14(1) exploitation reporting requires knowing what's in your product)
  4. 24h exploitation reporting process — Document who receives CVE alerts, who notifies ENISA/NCA, what the escalation path is (Art.14(1))
  5. No secrets in source code — Secret scanning pre-commit hook + CI gate (Art.12(3)(d))
  6. MFA for all admin access — Enforce MFA for all users with admin, billing, or infrastructure access (Art.12(3)(b))
  7. Authorization audit — Verify every API endpoint has explicit authorization check; test with a second tenant (Art.12(2))
  8. TLS 1.3 enforcement — Disable TLS 1.0/1.1, verify TLS 1.2 cipher hardening (Art.12(3)(c))
  9. Dependency update automation — Dependabot or Renovate with merge policy for patches (Art.12(1))
  10. Security logging baseline — Auth events, authorization failures, and admin actions logged to tamper-resistant storage (Art.12(5))

What's Next: The ENISA Secure by Design Series

This post is the foundation layer — the "why" and "what" of ENISA's SbD framework. The remaining four posts in this series go deeper into specific implementation challenges:

PostTopicFocus
#1349 (this post)ENISA SbD Playbook OverviewCRA mapping, 22 checkpoints, EU tooling
#1350Secure by Default: CRA Art.12(2) HardeningDefault configurations, attack surface reduction
#1351Vulnerability Management & SBOMCRA Art.14, dependency governance, SBOM workflows
#1352Security Update MechanismsCRA Art.14(4), auto-updates, patch deployment
#1353ENISA SbD Compliance Stack FinaleComplete developer toolkit, EU-sovereign options

The sota.io Connection

All five posts in this series assume you're deploying on infrastructure where the security controls you implement actually remain under EU jurisdiction — where your CLOUD Act exposure doesn't undermine the CRA compliance posture you're building.

sota.io runs on Hetzner Germany. No US parent company. No CLOUD Act exposure. Your deployment pipeline, secrets, runtime data, and security logs stay in EU jurisdiction throughout.

The September 2026 CRA deadline doesn't move. Neither does the principle: security starts at the infrastructure layer.

EU-ENISA-SECURE-BY-DESIGN-2026 Series: #1349 ENISA SbD Overview | #1350 Secure by Default | #1351 SBOM & Vulnerability Management | #1352 Security Update Mechanisms | #1353 Compliance Stack Finale

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Join the waitlistView pricing