Cyber Resilience Act Reporting Obligations: A DevOps Runbook

On 11 September 2026 a rule that engineering teams had filed under later quietly became a pager problem. Article 14 of the Cyber Resilience Act started to apply that day, and with it a clock that begins at the moment a manufacturer becomes aware that one of its products is being exploited. Nothing in the rest of the Regulation had to be ready yet. This one did.

I read the Commission's reporting page, ENISA's FAQ and factsheet for the Single Reporting Platform, the OpenSSF community guide, and the text of Regulation (EU) 2024/2847 itself, and turned them into a runbook. Research date: 17 October 2026. I have not filed a report myself, so everything here is a reading of those sources, not field experience, and anything I could not trace to them is left out.

This post is engineering guidance, not legal advice. Whether your product is in scope, who counts as the manufacturer and when you became aware are legal questions for your counsel. The authentic text of the Regulation is the one published on EUR-Lex, and ENISA's pages may have changed since 17 October 2026.

Two triggers, one date, and a duty that reaches products already sold

Article 14 creates two reporting duties. The first is an actively exploited vulnerability, meaning one with reliable evidence that a malicious actor has exploited it without the system owner's permission (ENISA FAQ 7). The second is a severe incident having an impact on the security of the product. Article 14(5) calls an incident severe where it negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to malicious code being introduced or executed in the product or in a user's network and information systems.

The date is in Article 71(2): the Regulation applies from 11 December 2027, but Article 14 applies from 11 September 2026. The part that surprises teams is Article 69(3). Article 69(2) says products placed on the market before 11 December 2027 only fall under the Regulation after a substantial modification, but Article 69(3) derogates from that for Article 14, so the reporting duty applies to all in-scope products already on the market. Your installed base is covered even if it never needs CE marking. In the other direction, ENISA's FAQ 13 says a manufacturer that became aware of exploitation before 11 September 2026 does not have to report it retrospectively.

The clocks: 24 hours, 72 hours, then two different final reports

Both event types share the first two stages and diverge at the end. The table condenses Article 14(2) and 14(4), and the Commission's reporting page and ENISA's factsheet state the same four deadlines. Each stage says unless the relevant information has already been provided, so a later report does not need to repeat what an earlier one carried.

Note the asymmetry in the last stage. The vulnerability clock is triggered by a fix existing, so it can start days after the first two. The incident clock is triggered by your own earlier notification. Write them into the runbook as two separate timers, because a single timer called reporting deadline will be wrong for one of them.

Awareness is the start line, so log it like a timestamp

Every deadline counts from the manufacturer becoming aware. That makes the moment you record awareness the most important line in your incident log, and it should be a UTC timestamp written by a person with authority to write it, not reconstructed from chat scrollback the next day. Whether a given alert amounts to reliable evidence of exploitation is a judgement your counsel and security lead have to make in advance, not during the incident.

The script below turns that one timestamp into the four deadlines. It uses GNU date, so on macOS install coreutils and swap in gdate. The final-report lines stay blank until you know the fix time or the notification time, because those are the real triggers.

#!/usr/bin/env bash
# cra-clocks.sh: turn ONE awareness timestamp into the Article 14 deadlines.
# GNU date. On macOS: brew install coreutils, then replace date with gdate.
#
#   ./cra-clocks.sh 2026-10-19T08:30:00Z
#   FIX_AT=2026-10-21T16:00:00Z ./cra-clocks.sh 2026-10-19T08:30:00Z
#   NOTIFIED_AT=2026-10-21T07:50:00Z ./cra-clocks.sh 2026-10-19T08:30:00Z
set -euo pipefail

AWARE="${1:?usage: cra-clocks.sh <awareness-timestamp-UTC>}"
t0=$(date -u -d "$AWARE" +%s)
fmt() { date -u -d "@$1" +%Y-%m-%dT%H:%M:%SZ; }

echo "aware               $(fmt "$t0")"
echo "early warning by    $(fmt $((t0 + 24 * 3600)))   # Art. 14(2)(a), 14(4)(a)"
echo "notification by     $(fmt $((t0 + 72 * 3600)))   # Art. 14(2)(b), 14(4)(b)"

# Vulnerability: the final report is keyed to the FIX, not to awareness.
if [ -n "${FIX_AT:-}" ]; then
  echo "vuln final report   $(date -u -d "$FIX_AT + 14 days" +%Y-%m-%dT%H:%M:%SZ)   # Art. 14(2)(c): no later than"
else
  echo "vuln final report   (set FIX_AT when a corrective or mitigating measure is available)"
fi

# Incident: the final report is keyed to YOUR OWN notification submission.
if [ -n "${NOTIFIED_AT:-}" ]; then
  echo "incident final      $(date -u -d "$NOTIFIED_AT + 1 month" +%Y-%m-%dT%H:%M:%SZ)   # Art. 14(4)(c)"
else
  echo "incident final      (set NOTIFIED_AT when the 72-hour notification is submitted)"
fi

One platform quirk is worth knowing before you trust a countdown. ENISA's FAQ 26 says that at present the 72-hour counter is calculated from 48 hours after the early warning, so a report can look overdue early, and that a future release will use the awareness date. It also says there is no final report counter for vulnerabilities. Keep your own clock; treat the platform's as a hint.

Filing it: one platform, the right CSIRT, and a login you should rehearse

Article 14(7) sends notifications through the single reporting platform that Article 16 establishes, to the electronic end-point of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA. The Commission's page and ENISA's factsheet add the rest of the flow: the receiving CSIRT passes the notification without delay to the CSIRTs in the Member States where the product is available, and may delay that only in exceptional circumstances under Article 16(2), which Commission Delegated Regulation (EU) 2026/881 specifies.

Choosing the CSIRT is not a formality. ENISA's FAQ 18 warns that selecting the wrong coordinator may invalidate the notification and force you to resubmit, so settle it before an incident. Article 14(7) gives the order:

1. Main establishment: the Member State where decisions related to the cybersecurity of your products are predominantly taken.
2. If that cannot be determined: the Member State where you have the establishment with the highest number of employees in the Union.
3. With no establishment in the Union, the Member State of the authorised representative acting for the most of your products, then of the importer placing the most, then of the distributor making available the most.
4. Last in that order: the Member State where the highest number of users of your products are located.

Access runs on EU Login with multi-factor authentication, and accounts are personal (FAQ 9). A manufacturer has one Primary Assigned Representative and up to 20 Secondary ones, the Primary must be verified by the CSIRT before inviting others, and drafts live in the individual's account, invisible to colleagues. Verification runs in parallel with reporting, and up to 20 notifications can be submitted before it becomes mandatory. There is no API at launch, the interface is English only, and if the platform is unavailable you may contact the coordinating CSIRT directly but must still submit through the platform once it is restored (FAQ 15, 24, 25).

Open-source dependencies: your duty, their silence

Article 13(5) tells manufacturers to exercise due diligence when integrating third-party components, including free and open-source components that were not made available in the course of a commercial activity. Article 13(6) goes further: on identifying a vulnerability in a component, including an open-source one, the manufacturer must report it to the person or entity manufacturing or maintaining that component, address it under Part II of Annex I, and, if it developed a modification, share the relevant code or documentation with them, where appropriate in a machine-readable format.

The OpenSSF guide, last updated 12 October 2026, is explicit about who is on the hook. The 11 September duty applies to manufacturers, not to maintainers merely because they maintain an open-source project. A manufacturer that finds an exploited flaw traced to an upstream component is responsible for the report but may contact the project, its maintainers or its steward. Open-source stewards have reporting duties under Article 24(3) from 11 December 2027, and OpenSSF notes that the Article 13(6) interaction is not part of the September milestone.

The practical consequence is an inventory problem. When a component is reported as exploited you need to know within hours which of your products ship it, and at which version. The query below assumes you keep one CycloneDX JSON SBOM per release; the field names are CycloneDX's, and the package name is a placeholder.

# Which releases ship a given component, and at which version?
# Assumes one CycloneDX JSON SBOM per release under sboms/. The package name is a placeholder.
# Article 13(6): once you know, you must also report the flaw UPSTREAM to the maintainer.
COMPONENT="example-lib"

for f in sboms/*.cdx.json; do
  jq -r --arg c "$COMPONENT" --arg f "$f" '
    .components[]?
    | select(.name == $c)
    | [$f, .name, .version, (.purl // "no-purl")] | @tsv' "$f"
done | sort

Where this goes wrong, and what it costs

The failure modes are mostly mundane. The wrong coordinating CSIRT can invalidate a notification. There is no API, so a notification is typed or pasted into a web form at the worst possible hour. Drafts are private to one account, so the engineer who started a report is the only one who can see it until it is submitted. The platform's 72-hour counter currently looks overdue early. And if the platform is down, the fallback is a phone call to the CSIRT followed by a resubmission, which only helps if someone already knows which CSIRT that is.

Two obligations sit next to the reports and are easy to forget. Article 14(8) requires the manufacturer to inform impacted users, and where appropriate all users, of an actively exploited vulnerability or severe incident, and of mitigations, where appropriate in a structured machine-readable format. If you fail to do so in a timely manner, the coordinating CSIRTs may inform the users themselves. Separately, ENISA's FAQ 30 says non-manufacturers should contact their national CSIRT directly, and submissions they make to the platform may be marked invalid.

The trade-off I cannot resolve for you is scope. Which of your products are products with digital elements, and which of your teams count as the manufacturer, depends on definitions I have not tried to interpret here. If you are unsure, the cost of a wrong guess is asymmetric: late reporting is a breach, early reporting of a borderline case is at worst a conversation with a CSIRT.

A runbook record that matches what the platform asks for

ENISA's FAQ 11 lists fields the platform may ask for: for vulnerabilities, a CVE ID, an EUVD ID, exploitation details, severity, the malicious actor and the nature of the exploit; for incidents, the nature of the incident, mitigation measures, severity and the likely threat or root cause. Required fields vary by stage, and the SRP Glossary marks each as required, optional, conditionally required or carried forward. The record below holds those fields and the Article 14 content in one file per event, so the first-hour responder fills it in once and every later stage copies from it.

# incidents/2026-10-19-example-product.cra.yaml  (one file per event)
event_type: actively_exploited_vulnerability   # or: severe_incident
product: example-product 4.2.1
coordinating_csirt: <member state>             # Art. 14(7); decided BEFORE the incident
aware_at_utc: 2026-10-19T08:30:00Z             # written by the person authorised to declare awareness
member_states_available: [DE, FR, NL]          # asked for in the 24h early warning

early_warning:                                 # due: aware_at + 24h
  submitted_at_utc: null
  suspected_unlawful_or_malicious: null        # incidents: include at least this

notification:                                  # due: aware_at + 72h
  submitted_at_utc: null
  cve_id: null                                 # FAQ 11 lists CVE ID and EUVD ID
  euvd_id: null
  nature_of_exploit_and_vulnerability: ""
  measures_taken: []
  measures_users_can_take: []
  sensitivity_of_information: ""               # Art. 14(2)(b): how sensitive you consider it

final_report:
  fix_available_at_utc: null                   # vulnerability: due 14 days after this
  notification_submitted_at_utc: null          # incident: due one month after this
  description_severity_impact: ""
  malicious_actor: ""                          # where available
  security_update_details: ""                  # vulnerability
  threat_type_or_root_cause: ""                # incident
  mitigation_applied_and_ongoing: []           # incident

user_notice:                                   # Art. 14(8), separate from the reports
  sent_at_utc: null
  machine_readable_advisory: ""

upstream:                                      # Art. 13(6), when a third-party component is involved
  component: null
  maintainer_notified_at_utc: null
  fix_shared_with_maintainer: null

I would commit this template to the incident repository and keep one filled-in copy per event. The point is not the format; it is that nobody is composing a regulatory submission from memory.

What to do on Monday

Five steps, in the order I would do them. None of them needs a decision from the Commission.

1. Name the manufacturer entity for each product line and write down which Member State's CSIRT is the coordinator under Article 14(7), with the reason.
2. Decide who is authorised to declare awareness, and make logging that UTC timestamp the first step of your incident template.
3. Register a Primary Assigned Representative and at least one Secondary on EU Login with MFA, and do one dry run of the login on the on-call device.
4. Put the SBOM query in the on-call runbook and check it returns something for your most-used open-source component.
5. Add the two final-report timers to the template separately: 14 days after a fix, and one month after the incident notification.

Open-source maintainers have a lighter Monday: keep a SECURITY.md with a private disclosure path and a current contact, and find out which steward or foundation would coordinate with a manufacturer. That is OpenSSF's advice, not a legal requirement for you.

The rule to carry: the Article 14 clock starts when you become aware, not when you finish triaging, and it is a manufacturer's duty even when the flaw lives in someone else's open-source code. Decide the entity, the CSIRT, the people with logins and the awareness timestamp before the first incident, because after it you have 24 hours.