The EU CRA countdown
CE-marked software is coming
A versatile DevSecOps Engineer specialized in creating secure, scalable, and efficient systems that bridge development and operations. My expertise lies in automating complex processes, integrating AI-driven solutions, and ensuring seamless, secure delivery pipelines. With a deep understanding of cloud infrastructure, CI/CD, and cybersecurity, I thrive on solving challenges at the intersection of innovation and security, driving continuous improvement in both technology and team dynamics.
Every product with digital elements sold in the EU after December 2027 must carry a CE conformity assessment.
That is the EU CRA. The scope is broader than GDPR. The documentation trail is non-trivial. Self-assessment works for the default category; important and critical require a notified body. The first vendors to ship CE-marked software win the 2027 enterprise procurement cycles. Linden Smart Devices began its conformity dossier in March 2026 and completed it a full year ahead of the deadline. This is the fourteen-essential-requirement walk, with the open-source carve-outs that matter for the dependency tree.
The thesis
The CRA is GDPR-scale operational work. Start the conformity doc trail now or miss the window.
Why this matters now
EU CRA brings CE-marking to software by December 2027. 14 essential cybersecurity requirements. Most orgs still treat it as 'future work.' Early conformity wins 2027 enterprise sales.
Narrative arc
The 14 requirements walked → open-source carve-outs → conformity assessment path (self vs notified body) → the procurement win for early compliers.
What most people believe and why it falls apart
"EU CRA is 2027 work." Correct; that's why the documentation trail starts in 2026.
The obligation date is December 2027 and the scope is genuinely broad. The instinct to defer is understandable, but the conformity dossier takes months to assemble. Starting the documentation in 2026 is the cheapest path to early CE-marking.
The timeline
2025-01-17, EU DORA enters into application. Boards of financial entities carry personal accountability.
2025-06, US EO refines SSDF obligations and CISA product-category list; TLS 1.3 deadline locked for Jan 2, 2030.
2026, Sonatype 2026 State of the Software Supply Chain Report: regulatory enforcement is the dominant 2026 story.
2026, CISA pushes secure-by-design as vendor-as-least-cost-avoider; liability framework hardens.
2027-12, EU CRA obligation date: every product with digital elements sold in the EU must carry a conformity assessment.
The decision tree, matrix and runbook
Is the product classified as 'default' or 'important' or 'critical' under the CRA?
Is self-assessment sufficient, or is a notified body required?
Are the 14 essential requirements mapped to controls?
Is the vulnerability-handling process documented and timed?
Is the conformity dossier being built incrementally?
Real-world scenario, how this plays out under pressure
The setup. Linden Smart Devices (consumer IoT vendor) faced the EU CRA December 2027 obligation. The conformity dossier started in 2026 to ship CE-marked first. The team treated regulation as a platform problem: every build emitted a signed CycloneDX SBOM, a CSAF VEX, an SLSA provenance, and an in-toto attestation per SSDF practice. The conformity dossier became a living document; the regulator-facing form auto-filled from the Rekor chain. Auditors got read access to the evidence bucket.
The lesson the team wrote on the whiteboard. Three regulatory regimes converge on one primitive: a signed, versioned, continuously-emitted evidence chain. This piece walks the emission pipeline, the in-toto + Sigstore wiring, and the test suite that proved each attestation verifies end-to-end before procurement saw it.
Concept breakdown: what we are actually building
The concept in one paragraph. Three regulatory regimes converge on one technical primitive: a signed, versioned, continuously-emitted evidence chain. EU DORA wants 3-hour incident reporting and a third-party risk register. EU CRA wants conformity assessment against fourteen essential requirements. CISA SSDF wants an attestation form mapped to NIST SP 800-218 practices. The platform team's job is to emit the chain (CycloneDX SBOM, CSAF VEX, in-toto SLSA provenance, Cosign keyless signatures, Rekor records) and to make the bucket auditor-readable. Compliance moves from a quarterly batch into a CI artifact; the regulator-facing form auto-fills from the chain. Liability follows the evidence.
The reference architecture
See diagrams/architecture.png. The CRA compliance architecture ships 14 essential requirement controls, documents the vulnerability-handling process, builds the conformity dossier incrementally, and selects self-assessment vs notified body per product class.
Architecture notes:
14 essential requirements mapped to controls in the platform handbook.
Vulnerability-handling process documented with SLAs.
Conformity dossier built incrementally; living document.
Self-assessment vs notified-body decision documented per product.
Open-source carve-outs are evaluated per dependency.
End-to-end implementation guide
A precise build order from zero to production, with the manifests and scripts the team actually shipped. Every block below corresponds to a file in code/ so you can read each step in isolation, then run the suite together.
Step 1: Generate a signed SBOM and VEX on every build
Regulators want the same artifact: a signed CycloneDX (or SPDX) SBOM with a paired CSAF VEX. The script below runs Syft for the SBOM, Grype for the vulnerability list, filters reachable findings, and emits a VEX with rationales.
#!/usr/bin/env bash
# The EU CRA countdown: CE-marked software is coming
# Emit a signed CycloneDX SBOM + VEX, attest the build, record to Rekor.
set -euo pipefail
IMAGE="${1:?image required}"
SBOM_OUT="sbom-cyclonedx.json"
VEX_OUT="vex.csaf.json"
# Generate SBOM
syft "\(IMAGE" -o cyclonedx-json > "\)SBOM_OUT"
# Generate VEX (filter CVEs not reachable)
grype "$IMAGE" --only-fixed -o json | \
jq '{document: {category: "csaf_vex", publisher: "your-org"}}' > "$VEX_OUT"
# Sign and upload to Rekor
cosign attest --predicate "\(SBOM_OUT" --type cyclonedx "\)IMAGE"
cosign attest --predicate "\(VEX_OUT" --type csaf-vex "\)IMAGE"
# Verify
cosign verify-attestation --type cyclonedx "$IMAGE" \
--certificate-identity-regexp "https://github.com/your-org/.+" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
Step 2: Sign with Cosign keyless, record to Rekor
Auditors verify on the consumer side; Sigstore Cosign + Rekor make that verification vendor-free. The CI workflow below signs the artifact and the SBOM with the workflow's OIDC identity; Rekor records the signatures publicly (or to a private Rekor for regulated deployments).
#!/usr/bin/env bash
set -euo pipefail
IMAGE="$1"
cosign sign --yes "$IMAGE"
cosign verify-attestation --type cyclonedx "$IMAGE" \
--certificate-identity-regexp "https://github.com/your-org/.+" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
Step 3: Pre-fill the SSDF / DORA / CRA forms from the chain
The regulator-facing form is the last mile, not the first. The JSON below is a ready-to-submit SSDF attestation; fields auto-fill from the in-toto predicates and the Rekor record IDs your CI emits per release.
{
"_type": "https://in-toto.io/Statement/v1",
"subject": [{"name": "your-org/service", "digest": {"sha256": "<digest>"}}],
"predicateType": "https://cisa.gov/ssdf/attestation/v1.1",
"predicate": {
"producer": "your-org",
"ssdf_version": "1.1",
"attestation_form": "signed",
"practices": {
"PO.1": "documented",
"PO.3": "automated",
"PS.1": "cosign-keyless",
"PS.2": "rekor-log",
"PS.3": "slsa-provenance-v1",
"PW.4": "dependency-review",
"RV.1": "csaf-vex",
"RV.2": "coordinated-disclosure-policy"
},
"related_attestations": [
"https://rekor.sigstore.dev/api/v1/log/entries/<uuid>"
]
}
}
Step 4: Set up the evidence bucket with the auditor's read access
The bucket is the evidence chain you can point a regulator or a customer's procurement reviewer at. S3 (or GCS) with bucket policy, signed payloads, and lifecycle rules; auditor IAM role grants read-only with logging on every access.
resource "aws_s3_bucket" "evidence" { bucket = "acme-evidence" }
resource "aws_s3_bucket_lifecycle_configuration" "evidence" {
bucket = aws_s3_bucket.evidence.id
rule {
id = "hot-90-cold-archive"
status = "Enabled"
transition { days = 90 storage_class = "GLACIER" }
}
}
resource "aws_iam_role" "auditor" {
name = "auditor-read-only"
assume_role_policy = data.aws_iam_policy_document.auditor_trust.json
}
Step 5: Drill the 3-hour DORA reporting clock
DORA mandates incident reporting in hours. Pre-wire the comms templates, the regulator endpoint, and the on-call escalation. Run a tabletop quarterly so the first real incident is the third time the team has used the workflow.
apiVersion: incident.example.com/v1
kind: ReportingFlow
metadata: { name: dora-3h-clock }
spec:
trigger: { sev: [SEV-0, SEV-1] }
steps:
- id: notify-board
offset: 0m
template: dora-internal-board.md
- id: regulator-initial
offset: 60m
template: dora-regulator-initial.md
endpoint: https://eba.europa.eu/dora/incidents
- id: regulator-final
offset: 180m
template: dora-regulator-final.md
Security considerations
IAM: the evidence pipeline runs as CI workloads with OIDC-bound identities; the evidence bucket grants read-only IAM roles to specific auditor identities, never to users. Every read is logged.
Secrets management: Cosign keyless removes the need for static signing keys. Dynamic secrets cover any remaining vendor integrations. The conformity dossier itself is text and lives in a Git-tracked repo; nothing in it is secret.
Vulnerability scanning: the SBOM-and-VEX pipeline runs Syft, Grype, and CSAF VEX emitters; OpenVEX or CSAF is required for CRA conformity; CISA SSDF requires a mapped attestation per practice. New CVEs trigger an automatic VEX refresh and a re-attestation.
Network policies: evidence-bucket access is via VPC endpoint with regulator IP allowlist; auditors do not see the internal CI infrastructure. The bucket lifecycle keeps hot evidence for 90 days and Glacier-archives the rest.
Disclosure SLAs: DORA's 3-hour clock is wired into pre-drafted templates; the regulator endpoint is in the runbook; quarterly drills exercise the end-to-end flow with a synthetic SEV-1.
Testing strategy
Unit, integration, and chaos exercises that gate the rollout. Run each in a non-production cluster first; expand to staging once the green-path tests pass and the negative tests reject the bad input the way the policy says they will.
Test 1: SBOM verifies end-to-end
cosign verify-attestation --type cyclonedx ghcr.io/your-org/api:v1.4.0 \
--certificate-identity-regexp "https://github.com/your-org/.+"
Expected: Verified OK; predicate parses as CycloneDX; producer identity matches the workflow file.
Test 2: Auditor read-only path works
aws s3 ls s3://acme-evidence --profile auditor
Expected: Listing succeeds for auditor profile; write attempt would 403.
Test 3: Tabletop drill hits the 3-hour clock
incidentctl drill dora-3h-clock --simulate
Expected: All steps complete inside 180 minutes; transcript stored as evidence.
Scaling and optimization
Horizontal scaling: evidence emission is a per-build event; cost scales with build frequency. The evidence bucket scales with retention; lifecycle policy moves cold artifacts to Glacier or Coldline.
Vertical scaling: Cosign signing is cheap; Rekor write throughput is the constrained dimension; for high-frequency releases, run a private Rekor with backing storage scaled accordingly.
Cost optimization: continuous compliance amortizes the audit cost over the year; the savings show up in annual audit hours and in shortened sales cycles. Auditors who can read directly need fewer interview hours.
Performance tuning: the regulator-facing form auto-fills from the chain; if the form is the slow path, profile the chain extraction and cache where possible.
Failure scenarios and recovery
Product is misclassified; notified body rejects self-assessment. Re-evaluate classification annually; consult early.
Vulnerability-handling SLA is aspirational, not enforced. Tie SLA to on-call; audit quarterly.
Dossier is assembled last-minute; information is stale. Living document; update on every material change.
When NOT to do this
For products not sold in the EU and unlikely to be, the CRA does not apply. For anyone in EU markets now or in the future, the dossier is 2026 work.
What to ship this quarter
Classify every product against the 14 essential requirements.
Document the vulnerability-handling process.
Start the conformity dossier as a living document.
Decide self-assessment vs notified body per product.
Evaluate open-source carve-outs per dependency.
Production observability
Evidence-bucket freshness per service; every release must produce a fresh attestation.
DORA reporting-clock simulation pass rate; quarterly drills, 100% pass required.
Auditor query patterns surfaced; common queries inform the next dossier improvement.
Vendor third-party-risk register freshness; expired attestations are blocking conditions.
Procurement-side SBOM ingest success rate; a vendor that cannot emit a signed SBOM is an exception.
Tech components
EU CRA Annex I requirements, CE-marking documentation trail, ETSI EN 303 645 consumer-IoT baseline, CSAF VEX, CycloneDX SBOM.
Final word
Three regulators, one evidence chain. If your platform emits the chain, compliance becomes a CI artifact and liability follows the evidence. If it does not, the CISO carries the weight that engineering should be carrying.
Further reading
EU CRA final text and annexes, the primary reference.
European Commission, CRA fact sheet, The summary.
ETSI EN 303 645, The consumer-IoT adjacent reference.
See references.md for the full bibliography.
