CRA Art.27 Technical Documentation & SBOM Requirements 2026

Post #16 in the sota.io EU Cyber Compliance Series

When the Cyber Resilience Act becomes fully enforceable in December 2027, manufacturers of connected digital products must maintain comprehensive technical documentation covering everything from architectural design to every software component in the product — with a mandatory ten-year retention period. Article 27, read together with Annex VII, establishes the most extensive product documentation regime in EU tech regulation history.

For most software teams, the practical challenge is not writing the documentation — it is ensuring that documentation remains accurate and complete when it matters most: during a security incident. This is where cloud provider jurisdiction creates a compliance gap that no amount of internal process can close.

What CRA Article 27 Actually Requires

Article 27 states that manufacturers must draw up technical documentation "before placing the product with digital elements on the market." The documentation must be continuously updated throughout the product's supported lifecycle and retained for at least ten years after the product is placed on the market or after the end of the support period, whichever is longer.

Annex VII enumerates seven mandatory documentation categories:

1. General description — product purpose, intended use environments, supply chain components, and integration touchpoints with external systems
2. Design and development documentation — architectural diagrams, data flow maps, security design decisions, and rationale for security controls selected or rejected
3. Risk assessment — as required by Annex I Part 2, covering threat modelling, vulnerability assessment, and residual risk documentation
4. SBOM — a complete Software Bill of Materials listing every software component including open source libraries, third-party packages, and their respective versions and known vulnerability status
5. Vulnerability handling procedures — documented processes for CVE discovery, triage, patching, and disclosure aligned with Article 14 timelines
6. Testing and evaluation results — penetration test results, fuzzing results, static analysis outputs, and conformity assessment records
7. EU Declaration of Conformity — the formal self-declaration or notified body assessment certificate required for CE marking

The SBOM requirement (category 4) is the most operationally demanding. The CRA does not prescribe a specific SBOM format, but market guidance from ENISA and the Commission's technical working groups points strongly toward CycloneDX 1.5+ or SPDX 2.3+ as the expected interchange formats. These formats support machine-readable dependency trees, license information, and — critically — purl (Package URL) identifiers that can be cross-referenced against public vulnerability databases including ENISA's own EUVDB.

The Ten-Year Retention Obligation

The ten-year retention requirement is often under-appreciated by legal and engineering teams focused on the December 2027 compliance deadline. Consider the practical implications: a product placed on the market in January 2028 generates an Art.27 documentation obligation that runs to January 2038. If the product receives a major update in 2030 that resets the support period, the documentation clock resets accordingly.

This means documentation infrastructure — not just the documents themselves — must be built for decade-scale reliability. Version-controlled documentation repositories, automated SBOM generation in CI/CD pipelines, and immutable audit logs of vulnerability discoveries and patches are not nice-to-haves under CRA; they are implicit requirements of the ten-year retention mandate.

Market surveillance authorities (MSAs) — the national regulators empowered to enforce the CRA under Article 41 — have the right to request this technical documentation at any time during the retention period. An MSA request that cannot be fulfilled because records were lost, corrupted, or silenced by a third-party legal order is a compliance failure regardless of intent.

How US-Hosted Infrastructure Creates a Documentation Gap

Here is the structural problem that neither legal teams nor cloud vendor sales representatives adequately disclose: when your product's infrastructure runs on a US-headquartered cloud provider, that provider is subject to the Foreign Intelligence Surveillance Act (FISA) and the CLOUD Act (18 U.S.C. § 2713). These US statutes authorize law enforcement and intelligence agencies to serve National Security Letters (NSLs) or court orders that include mandatory non-disclosure provisions — commonly called gag orders.

An NSL gag order prohibits the recipient — your cloud provider — from disclosing to anyone, including you as their customer, that the order was served. The provider cannot tell you that your infrastructure was accessed, that your data was reviewed, or that a security event affecting your systems occurred under the order's authority.

Under CRA Article 27, your technical documentation must include:

• A complete record of security incidents affecting the product
• The vulnerability handling procedures actually followed (not just the intended procedures)
• Testing and evaluation results that reflect the real security posture of the product

If a security incident occurs during a period when your US-hosted cloud provider is subject to an NSL gag order, you have a direct conflict:

• Art.27 obligation: Document the security incident completely and accurately
• NSL gag order effect: Your cloud provider cannot disclose the incident's existence or scope to you, making accurate documentation structurally impossible

This is not a theoretical risk. The US government serves approximately 12,000–15,000 NSLs annually across all US tech companies (the aggregate figures visible in transparency reports before gag orders lift). For infrastructure providers serving European enterprise customers — the exact customer segment covered by CRA — the incentive to serve NSLs increases with the sensitivity of the hosted workloads.

The SBOM Jurisdiction Problem

The SBOM requirement interacts with US jurisdiction in a second way: open source component supply chains.

When a vulnerability is discovered in an open source library hosted on GitHub (a Microsoft Corporation asset subject to CLOUD Act), the coordinated disclosure process often involves GitHub Security Advisories and the GitHub Advisory Database. These are US-law-jurisdiction systems. Before a CVE is published, there is typically a disclosure embargo period during which the vulnerability details are known to the maintainer and the reporting researcher but not yet public.

During this embargo period, US law enforcement could theoretically serve a FISA order or NSL on GitHub requiring disclosure of pre-public vulnerability information — or requiring non-disclosure of the same. For a product manufacturer whose SBOM includes that component, the embargo period is precisely the window when accurate vulnerability documentation is most critical (Art.14 requires ENISA notification within 24 hours of discovering an actively exploited vulnerability).

An EU-native git platform — Forgejo instances on Hetzner, Codeberg (Germany), or Gitea on EU-only infrastructure — removes this jurisdictional hook entirely. The maintainer operates under EU law, coordinated disclosure happens through ENISA's EUVDB, and there is no US-statute mechanism to insert a gag order into the embargo workflow.

What Manufacturers Must Document Before September 2026

The CRA's Art.14 ENISA notification requirements become active in September 2026 — fifteen months ahead of full Article 27 documentation compliance (December 2027). This creates a critical intermediate window: manufacturers must already have incident detection and documentation systems capable of triggering the 24-hour ENISA notification, even while the full Annex VII documentation regime is not yet formally required.

Practically, teams building for CRA compliance should treat September 2026 as the documentation readiness deadline for at least the following Art.27 categories:

Must be production-ready by September 2026:

• Vulnerability handling procedures (directly supports Art.14 24h notification)
• SBOM with current vulnerability status (needed to assess which product versions are affected)
• Incident logging infrastructure (must capture events with timestamps meeting Art.14 requirements)

Must be production-ready by December 2027:

• Complete Annex VII documentation set
• Ten-year retention infrastructure
• EU Declaration of Conformity

Three Documentation Architectures and Their CLOUD Act Risk Profiles

Architecture A: US-hosted cloud (AWS, Azure, GCP) with US SaaS tooling

Risk profile: HIGH. Infrastructure subject to CLOUD Act. Build system potentially on GitHub. Dependency update notifications via Dependabot (GitHub = Microsoft). Incident response tooling may include PagerDuty (US), Datadog (US), or Splunk (US). Each of these has independent US-law jurisdiction. An NSL gag order on any one of them creates a documentation gap in a different layer.

Architecture B: US-hosted cloud + EU-native tooling overlay

Risk profile: MEDIUM. Teams attempt to use EU-native monitoring (Grafana Cloud EU, self-hosted Prometheus/Loki) while remaining on US infrastructure for compute. The documentation gap still exists at the infrastructure layer — NSL gag orders are served on the compute provider, not the monitoring layer. If the security event originates at the infrastructure level (hardware access, hypervisor compromise, network interception), the EU-native monitoring overlay does not capture it.

Architecture C: EU-native infrastructure throughout

Risk profile: LOW. Compute on Hetzner (Germany), Scaleway (France), or OVHcloud (France). Source control on Codeberg or self-hosted Forgejo. Monitoring on self-hosted Prometheus/Grafana. Incident response tooling on EU-resident providers. No US-law jurisdiction hook at any layer of the stack. Art.27 documentation can capture the complete incident picture without gag-order risk.

Architecture C is not just a compliance preference — it is the only architecture that structurally guarantees Art.27 documentation completeness under adversarial conditions.

SBOM Implementation for CRA Compliance

For teams beginning SBOM implementation today, the minimal viable setup for September 2026 readiness requires:

Step 1: SBOM generation in CI/CD

Integrate a tool like Syft (Anchore), cdxgen, or the CycloneDX Maven/Gradle plugin into your build pipeline. Configure it to generate a CycloneDX 1.5 BOM at every production build. The BOM should include application dependencies, container base images, and OS packages. Store the BOM artifact alongside the build artifact.

Step 2: Vulnerability scanning against the SBOM

Connect the generated BOM to a vulnerability scanner (Grype from Anchore, OWASP Dependency-Check, or Trivy) that cross-references against NVD, GHSA, and — once operational — ENISA's EUVDB. Configure alerts for newly discovered CVEs affecting components in your current SBOM. This alert is the trigger for Art.14 assessment (is this an actively exploited vulnerability requiring 24h ENISA notification?).

Step 3: Immutable SBOM versioning

Each SBOM must be retained and linked to the product version it describes. Use a content-addressed storage system (git with tags, or an artifact registry with immutable tags) to ensure SBOMs cannot be retroactively modified. Art.27's ten-year retention requirement implies that market surveillance authorities may compare historical SBOMs against disclosed vulnerabilities to verify that manufacturers discovered vulnerabilities at the claimed time.

Step 4: Jurisdiction audit of SBOM components

Review each component in your SBOM for its governance jurisdiction. Open source projects hosted on GitHub are under US jurisdiction for any GitHub Security Advisory or coordinated disclosure process. Evaluate whether high-risk components (cryptography libraries, authentication modules, network stack components) should be mirrored to EU-jurisdiction infrastructure to remove the CLOUD Act hook from your disclosure coordination.

The Conformity Assessment Cascade

Article 27 documentation is not only a market surveillance obligation — it feeds directly into the conformity assessment process under Articles 18-33. For Class I products (the majority of B2B SaaS and developer tools), manufacturers can self-assess conformity. For Class II products (security-critical functions including products processing sensitive data categories), third-party notified body assessment is required.

In both cases, the technical documentation is the foundation of the assessment. A notified body conducting a Class II assessment will review the SBOM for completeness, audit the vulnerability handling records, and verify that documented security controls match the actual implementation. An assessment that finds gaps — including gaps caused by CLOUD Act silence during security incidents — can result in non-conformity findings that block CE marking and therefore market access in the EU.

For manufacturers targeting the EU market, the economic consequence is direct: products without CE marking cannot be legally placed on the EU market under CRA after December 2027. The conformity assessment cascade means that US-hosted infrastructure is not just a compliance risk — it is a potential market access blocker.

Timeline Summary

What EU-Native Hosting Changes

When compute, storage, and tooling operate entirely within EU jurisdiction, the Art.27 documentation obligation becomes structurally straightforward:

• Security incidents are captured completely — no US-law gag order can silence the infrastructure provider
• SBOM vulnerability disclosure follows EU-law coordination timelines without US NSL intervention risk
• Market surveillance authority requests can be fulfilled completely — the documentation record is not subject to third-party legal orders that the manufacturer cannot disclose

For products that will carry CE marking under CRA, the question of cloud provider jurisdiction is not a procurement preference — it is a compliance architecture decision with direct legal and market consequences.

The ten-year documentation retention clock starts with the first product placed on the EU market. Teams that establish EU-native documentation infrastructure today are building compliance capital for a decade. Teams that defer the jurisdiction question are accumulating compliance risk that grows more expensive to resolve the closer the December 2027 deadline approaches.

Related CRA posts in this series:

• CRA Art.16 Importer Obligations
• CRA Art.24 Open Source Steward Obligations
• CRA SBOM Requirements — Annex I
• CRA Art.14 Coordinated Vulnerability Disclosure
• CRA Art.11 Actively Exploited Vulnerabilities
• CRA Art.6 Product Classification
• CRA September 2026 120-Day Countdown