Implementing the CRA reporting obligation from 11.9.2026

The CRA reporting obligation hits manufacturers of products with digital elements from 11 September 2026: report actively exploited vulnerabilities provisionally within 24 hours, fully within 72 hours, and file the final report at the latest 14 days after a corrective measure becomes available. Under Art. 14(1) CRA the report goes simultaneously to the coordinating CSIRT and to ENISA, through a single submission.

What applies concretely from 11 September 2026

Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026; the remaining manufacturer obligations only from 11 December 2027. The reporting obligation therefore arrives fifteen months before everything else that hits a manufacturer. Anyone waiting for full applicability has already missed the first deadline.

A third date regularly gets lost: Chapter IV on notified bodies (Articles 35 to 51) has applied since 11 June 2026. It concerns conformity assessment bodies, not you as a manufacturer.

Two triggers, two chains of deadlines:

The clock runs from awareness, not from confirmation. Running an internal approval round first burns half the budget. Breaches of Articles 13 and 14 carry fines under Article 64(2) CRA of up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher.

Does the Cyber Resilience Act apply to Swiss companies?

Yes, as soon as a product with digital elements is placed on the market in the EU. Being based in Kreuzlingen, Zug or Zurich changes nothing. The only interesting question is which CSIRT a manufacturer without an establishment in the Union reports to.

Article 14(7) CRA solves that through a cascade: what governs is the member state where the authorised representative sits for the largest number of products. Failing that, the importer. Failing that, the distributor. If that remains open, the member state with the most users decides.

That is an architecture decision, not a legal footnote. Anyone who does not know today which national CSIRT is competent will not register in time on 11 September.

Where the report goes, and who your counterpart is

The report has two recipients and is nonetheless submitted only once. Article 14(1) CRA obliges the manufacturer to report an actively exploited vulnerability simultaneously to the CSIRT designated as coordinator and to ENISA. For severe security incidents, paragraph 3 says the same.

The technical route is one. Under Article 14(7) CRA the report goes through the reporting endpoint of the CSIRT designated as coordinator in the member state of the main establishment, and is simultaneously accessible to ENISA. The Commission puts it this way on its page on CRA reporting obligations: “Manufacturers report only once through the CRA Single Reporting Platform (SRP)”.

The party that comes back with questions is the CSIRT. Under Article 14(6) it may request an interim report, and it validates your access to the platform in advance. ENISA builds and operates it. If you want to know who you call in a real event: the CSIRT of your main establishment.

For implementation, three details from the ENISA FAQ on the SRP (as of 3 August 2026) matter more than any legal question:

• There is no API for now. You can automate everything up to submission; the submission itself is typed by a human into a browser form.
• Registration runs through EU Login (ecas.ec.europa.eu), with validation afterwards through the competent CSIRT. Both take time and belong before the real event.
• The platform was not yet live in mid-August 2026, and the public URL not yet published. It is meant to be operational by 11 September.

So the last metre of your chain is manual. All the more important that the forty-nine metres before it are not.

Two authorities regularly get filed wrongly here. Germany’s BSI has been the notifying and market surveillance authority for the CRA since October 2025. Market surveillance, however, is not receiving reports.

And Switzerland’s BACS is not an address in the CRA context at all. It is the addressee of the Swiss ISG reporting obligation, a separate regime with its own legal basis. Conflating the two means reporting to the wrong place.

The CRA and the Swiss ISG reporting obligation side by side

Two regimes, two addressees, two legal bases, both with a 24-hour deadline. A Swiss software manufacturer that supplies the EU and whose products are used by Swiss critical infrastructure falls under both. We built this comparison because we could not find one anywhere. Every row is evidenced against the statutory text.

The most interesting difference is in the last row. The CRA sanctions the omission directly. The ISG does not: under Art. 74g ISG BACS first sets a deadline, then issues an order, and only wilful disregard of that order is punishable under Art. 74h.

We know the same indirect construction from the revised Swiss DPA, where the Federal Data Protection Commissioner likewise has no direct sanctioning power. Anyone concluding from this that the ISG obligation is toothless is overlooking Art. 74h(1): the fine lands on natural persons, not on the company.

The figures come from BACS itself. In its semi-annual report 2025/2 (published 30 March 2026) the office processed 145 reportable cyber incidents in the second half of 2025, distributed across the public sector (25 %), IT and telecommunications (18 %) and finance and insurance (15.7 %). Alongside that, 64,733 voluntary reports across the full year.

What you have to build so that 24 hours is enough

Four artefacts have to be finished before the clock starts. None of them can be improvised during an incident.

1. An SBOM per release, stored immutably. Annex I Part II point 1 CRA requires a software bill of materials in a common machine-readable format covering at least the top-level dependencies. That is the legal floor, not the goal: stopping at transitive dependencies means missing Log4Shell-class problems.
2. A backwards-looking answer. The question in a real event is not “is the library vulnerable” but “which shipped versions contain it and who runs those”. That has to be a query, not a reconstruction.
3. An escalation path with a named person. Not “the security team” but a name and a deputy, with access to the registered EU Login account. At three on a Sunday morning.
4. An incident log with UTC timestamps. You do not only have to report within the deadline, you have to be able to prove that you did.

Five years of support, from 11 December 2027

Article 13(8) CRA sets the support period at a minimum of five years, shorter only where the product is expected to be in use for less time. Five years of security updates means five years of a working build pipeline for every still-supported release branch. That is the most expensive obligation in the whole CRA, and it appears in no reporting deadline.

If you are not sure whether your chain from detection to submitted form holds within a working day, run it once against a real, already-fixed vulnerability and time it. As an exercise that is an afternoon. What stands out is rarely the tooling and almost always the handover between two people.

SBOM in the pipeline: a setup that answers retrospectively

The SBOM belongs bound to the image digest, not to the tag. Tags get overwritten; digests do not. The workflow below produces both common formats, checks against CVE feeds, and signs the result keyless over OIDC. Versions as of August 2026: Syft v1.51.0, Grype v0.117.0, cosign v3.1.3.

# .github/workflows/release.yml
name: release
on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  packages: write
  id-token: write            # keyless signing, no key material in the repo

jobs:
  sbom:
    runs-on: ubuntu-24.04
    env:
      IMAGE: ghcr.io/${{ github.repository }}
    steps:
      - uses: actions/checkout@v7

      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build, push, capture the digest
        run: |
          docker build -t "$IMAGE:$GITHUB_REF_NAME" .
          docker push "$IMAGE:$GITHUB_REF_NAME"
          DIGEST=$(docker buildx imagetools inspect "$IMAGE:$GITHUB_REF_NAME" \
                     --format '{{ .Manifest.Digest }}')
          echo "REF=$IMAGE@$DIGEST" >> "$GITHUB_ENV"

      - name: Pin the tools to fixed versions
        run: |
          curl -sSfL https://get.anchore.io/syft  | sh -s -- -b /usr/local/bin v1.51.0
          curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin v0.117.0

      - uses: sigstore/cosign-installer@v4
        with:
          cosign-release: v3.1.3

      - name: Produce the SBOM in both formats
        run: |
          syft registry:"$REF" \
            -o cyclonedx-json=sbom.cdx.json \
            -o spdx-json=sbom.spdx.json

      - name: Check against CVE feeds, stop the build on anything critical
        run: grype "sbom:sbom.cdx.json" --fail-on critical

      - name: Bind the SBOM to the digest and sign it
        run: cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$REF"

      - uses: actions/upload-artifact@v7
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom.*.json
          retention-days: 90       # GitHub's maximum, so only a buffer

The upload-artifact step is the weakest point and deliberately left that way: in production the SBOMs belong in object storage with versioning and object lock, queryable by component. GitHub artefacts are an intermediate step, not an archive. More on this in our work on CI/CD and supply chain.

The incident log that evidences your deadline

An incident log is not a ticket history but an append-only event stream with UTC timestamps. NDJSON is enough, one line per event, ts always first. What matters is the machine-recorded moment of awareness, which nobody has to reconstruct later from a Slack history. The revised Swiss DPA demands the same discipline for personal data; what an audit log that survives a subject access request looks like we have described separately.

{"ts":"2026-09-14T07:12:41Z","event":"aware","incident":"INC-2026-0007","cve":"CVE-2026-31337","product":"acme-gateway","affected_versions":["3.4.0","3.4.1"],"component":"pkg:golang/github.com/example/parser@1.8.2","evidence":"WAF signature 8841, 3 hits from 2 source ASNs","actively_exploited":true,"detected_by":"grype-nightly+SIEM","owner":"r.segi"}
{"ts":"2026-09-14T07:41:02Z","event":"triaged","incident":"INC-2026-0007","regime":["cra","isg"],"cra_trigger":"actively_exploited_vulnerability","due_early_warning":"2026-09-15T07:12:41Z","due_notification":"2026-09-17T07:12:41Z","csirt":"NCSC-NL","owner":"r.segi"}
{"ts":"2026-09-14T09:03:55Z","event":"reported","incident":"INC-2026-0007","channel":"eu-srp","stage":"early_warning","reference":"SRP-2026-114872","elapsed_h":1.85,"submitted_by":"r.segi"}
{"ts":"2026-09-14T10:26:33Z","event":"reported","incident":"INC-2026-0007","channel":"ch-bacs-csh","stage":"first_report","reference":"BACS-2026-3391","elapsed_h":3.23,"submitted_by":"r.segi"}
{"ts":"2026-09-14T11:48:07Z","event":"users_informed","incident":"INC-2026-0007","format":"csaf-2.0","url":"https://acme.example/security/ACME-SA-2026-004"}

The deadlines in the triaged event are computed, not typed. That is a function, not a calendar entry:

// Deadlines under Art. 14 CRA, computed from the moment of awareness in UTC.
type Deadlines struct {
	EarlyWarning time.Time // 24 h from awareness
	Notification time.Time // 72 h from awareness
	Final        time.Time // 14 days after a corrective measure is available
}

func CRADeadlines(awareAt, fixAvailableAt time.Time) Deadlines {
	awareAt = awareAt.UTC()
	return Deadlines{
		EarlyWarning: awareAt.Add(24 * time.Hour),
		Notification: awareAt.Add(72 * time.Hour),
		Final:        fixAvailableAt.UTC().AddDate(0, 0, 14),
	}
}

Why go to this trouble for a log that will hopefully never be needed: because in a dispute the burden of proof is yours. Anyone wanting to go deeper on the principle will find it worked out in observability you actually read and in documenting architecture decisions.

What not to do now

Do not buy a compliance tool before you have run the reporting chain once against a real vulnerability. This is the recommendation we get the most pushback on, and we are sticking with it.

The market for CRA platforms has been loud since spring 2026, and the products almost all solve the same problem: they produce documents. The problem that breaks your deadline is the hour between “an alert came in” and “somebody with access decided this is reportable”.

The trade-off, named honestly: a tool is procured in two weeks; the rehearsal costs an afternoon plus the corrections afterwards. Anyone with nothing at all in September 2026 is better off with a purchased tool plus a rehearsal.

Where our recommendation does not fit: with more than a handful of product lines with different authorised representatives in the EU, “which product reports to which CSIRT” becomes a data management question. Then a tool is right from day one. With one product and one CSIRT it is burning money.

The second thing not to do: postponing registration until the real event. Create the EU Login, determine the CSIRT, start the validation. One morning, and the only task that cannot be caught up on 11 September.

Frequently asked

From when does the CRA reporting obligation apply?

From 11 September 2026, through Article 14 of Regulation (EU) 2024/2847. Three deadlines then run: 24 hours to the early warning, 72 hours to the full notification, and 14 days after a corrective measure becomes available to the final report — one month for incidents.

The remaining manufacturer obligations only become applicable on 11 December 2027. Chapter IV on notified bodies has applied since 11 June 2026.

Who has to report under the CRA?

The manufacturer of the product with digital elements, regardless of where it is based, as soon as the product is placed on the market in the EU. Reportable are actively exploited vulnerabilities in the product and severe security incidents affecting its security. Existing products are included. Affected users must additionally be informed, under Article 14(8) in a structured, machine-processable format where possible.

What is an SBOM and what do I need it for?

An SBOM (software bill of materials) is a machine-readable inventory of all components of a software artefact, usually in CycloneDX or SPDX format. The CRA requires one in Annex I Part II point 1, at least for top-level dependencies. In practice you need it to answer, within hours, which shipped versions contain a component that has just become known to be vulnerable.

Does a Swiss company have to report twice?

Possibly yes, but to different places and for different reasons. The CRA addresses you as the manufacturer of an EU product and means its vulnerabilities. The ISG obligation addresses you as an operator of critical infrastructure and means attacks on your own systems. A ransomware incident in your build system can trigger both at once.

What happens if the Single Reporting Platform is not running on 11 September?

The obligation arises from Article 14, not from the availability of the platform. In mid-August 2026 the SRP was not yet live and its URL not yet published. Record the moment of awareness and every attempt to submit, with a note where submission was technically impossible. In that situation a complete log is the only thing you hold.

---

If the chain is not yet in place. Two weeks remain to 11 September, and probably longer to the first realistic report. If you want to know whether your chain from detection to submitted form holds: thirty minutes with an engineer who has built SBOM pipelines and worked in regulated environments such as the form service for the Swiss FOITT. No sales pitch, no slides.

Book a slot directly or write briefly through contact about what you are building. We will tell you where we see the deadline breaking.

All legal references verified on 19 August 2026 against EUR-Lex and Fedlex. This article describes the technical implementation; it is not legal advice.