On September 11, 2026, the EU Cyber Resilience Act's first enforcement deadline arrives. Manufacturers placing products with digital elements on the EU market must have a process for reporting actively exploited vulnerabilities and serious cybersecurity incidents to ENISA within 24 hours of awareness. I wrote about this three weeks ago — the details, the FOSS implications, the ORC Working Group's guidance. That piece covered the CRA's substance.

What I didn't cover is what lands alongside it.

CIRCIA: The US Side of the Same Coin

The Cyber Incident Reporting for Critical Infrastructure Act passed Congress in 2022 as part of the Consolidated Appropriations Act. It directed CISA to write a rule requiring covered entities across the 16 critical infrastructure sectors to report covered cyber incidents within 72 hours and ransomware payments within 24 hours.

The statutory deadline for the final rule was October 2025. CISA missed it. The proposed rule came out in April 2024, and the final rule has been delayed — first by the normal regulatory process, then by a DHS shutdown in the spring of 2026 that pushed back stakeholder town halls. According to the latest Unified Agenda of Federal Regulatory and Deregulatory Actions, CISA now expects to issue the final rule in September 2026.

September. The same month the CRA's reporting obligations go live in the EU.

This is not a coincidence in timing, and it's not a coincidence in substance. Both regimes are built on the same premise: when a cyber incident happens, someone needs to know quickly, and the regulator needs to know too. The voluntary, post-hoc, whenever-it's-convenient model of incident disclosure is over. Both the EU and the US have decided — independently but convergently — that incident reporting is a legal obligation with a clock attached.

What CIRCIA Requires

The proposed rule, published in April 2024, covers entities in the 16 critical infrastructure sectors defined by Presidential Policy Directive 21: energy, water, healthcare, communications, financial services, food and agriculture, government facilities, and others. The scope is broad. A rural electric cooperative, a community water system, a small hospital, a regional food processor — all potentially covered.

The reporting triggers are:

Covered cyber incident (72 hours). A cyber incident that leads to substantial loss of confidentiality, integrity, or availability of an information system or information, or that impacts the ability to maintain operations. The report must include a description of the incident, the systems and data affected, and any response measures taken.

Ransomware payment (24 hours). If a covered entity pays a ransomware demand, the payment must be reported to CISA within 24 hours. The report must include the amount, the payment method, and any known information about the attacker.

The 72-hour clock starts when the entity has a reasonable belief that a covered incident has occurred. Not when it's confirmed. Not when the investigation is complete. When the entity reasonably believes it happened. This is the same "awareness" standard the CRA uses — the clock starts when you know, not when you're sure.

CISA held stakeholder town halls in June 2026 to discuss size thresholds, MSP coverage, and vendor reporting expectations. The final rule may adjust some of these parameters, but the core structure — 72 hours for incidents, 24 hours for ransomware payments — has been consistent throughout the rulemaking process.

The Convergence

Here's what September 2026 looks like for an organization operating in both jurisdictions — or for a software vendor whose products touch critical infrastructure in both markets:

September 11 (EU): If you manufacture a product with digital elements placed on the EU market, you must report actively exploited vulnerabilities affecting that product to ENISA within 24 hours of awareness.

September (US): If you operate covered critical infrastructure, you must report covered cyber incidents to CISA within 72 hours and ransomware payments within 24 hours.

Two regulatory bodies. Two reporting portals. Two sets of definitions for what constitutes a reportable event. Two timelines that start at different moments — the CRA's vulnerability clock starts when the manufacturer is aware of an actively exploited vulnerability; CIRCIA's incident clock starts when the entity reasonably believes a covered incident has occurred. But the operational reality is the same: something went wrong, you found out, and now you're on a legal clock to tell someone.

For organizations that operate across both jurisdictions — a multinational with EU customers and US critical infrastructure operations, or a software vendor whose products are used in both markets — September is when these two regimes start running simultaneously. The compliance overhead of maintaining two separate reporting processes, two sets of documentation, and two notification chains is real. But the underlying operational practice is identical: detect, assess, document, report.

The Infrastructure Ownership Argument

I've made this argument before, in the context of Bill C-22 (lawful access), Bill C-36 (privacy reform), and the CRA. CIRCIA makes it again, from a different angle.

Detection. The 72-hour clock starts when you reasonably believe a covered incident has occurred. If you run your own infrastructure — Proxmox nodes, Nextcloud, Matrix, Postgres, Keycloak — you see the alerts. You see the anomalous logins, the unusual network traffic, the failed service restarts. Your monitoring stack (Prometheus, Grafana, Loki, whatever you've built) tells you something is wrong. You are the first to know.

If you rent your infrastructure from a hyperscaler, you find out when the vendor notifies you. Vendors do not notify customers in real time. They investigate internally, assess legal exposure, prepare communications, and then notify. The time between "vendor detects incident" and "customer is notified" is not under your control. That interval counts against your 72-hour clock — but you don't know it's running.

Assessment. CIRCIA requires a description of the incident, affected systems and data, and response measures. If you own the stack, you have the logs. You have the network captures. You have the filesystem state. You can write the report from primary evidence.

If you rent, you request logs from the vendor. The vendor provides what they choose to provide, on their timeline, in their format. You write the report from secondary evidence — the vendor's summary of what happened to your data on their infrastructure. Under CIRCIA, you're the reporting entity. You're legally accountable for the accuracy and timeliness of a report built on information you had to request from a third party.

Response measures. The report must include what you've done in response. If you own the infrastructure, you've isolated the affected system, blocked the malicious IPs, rotated the compromised credentials, and restored from backup. You can describe these measures because you performed them.

If you rent, your response measures are: "We contacted the vendor. The vendor is investigating." That's a real response, but it's not one you control. The 72-hour clock doesn't pause while you wait for the vendor to act.

The MSP Question

CISA's June town halls specifically discussed how CIRCIA applies to Managed Service Providers. The proposed rule's language suggests that MSPs that experience incidents affecting their covered clients' systems are themselves subject to reporting obligations. This creates a dual reporting path: the covered entity reports the incident, and the MSP reports the same incident from their side.

For community infrastructure operators who use MSPs — a local IT provider managing your Nextcloud instance, a regional consultant maintaining your network — this means your MSP's incident response capability is now your compliance dependency. If your MSP detects an incident affecting your systems, they're on a clock to report. But you're also on a clock. The question is whether your MSP's detection-to-notification pipeline is fast enough to give you time to meet your own 72-hour obligation.

This is where the build-vs-buy decision gets concrete. A community organization running its own infrastructure with its own monitoring has a direct detection-to-reporting pipeline. A community organization using an MSP has a detection-to-MSP-to-notification-to-reporting pipeline, with each handoff adding latency and each latency eating into the compliance window.

The Ransomware Payment Problem

The 24-hour ransomware payment reporting requirement is the most aggressive timeline in either regime — EU or US. It's faster than the CRA's 24-hour vulnerability reporting, and faster than CIRCIA's 72-hour incident reporting. The message from Congress is unambiguous: if you pay a ransom, we want to know immediately.

The operational challenge is real. A ransomware payment decision often requires legal consultation, executive approval, and insurance carrier coordination. Organizations that have never paid a ransomware demand and don't have a pre-established decision process will struggle to make the payment, document it, and report it within 24 hours — especially if the payment happens over a weekend or holiday.

For community infrastructure operators: the best compliance strategy for the ransomware payment rule is to never need it. Offline backups. Tested recovery procedures. Network segmentation. The 24-hour reporting window is a backstop for when prevention fails. Prevention is still the primary control.

And prevention is more achievable when you own the stack. You control the backup schedule. You control the network segmentation. You control the access policies. You don't need to file a support ticket to restore from backup — you restore from backup.

The Broader Pattern

Three regulatory regimes now point the same direction:

  1. Bill C-36 (Canada): Document how you protect data, assess cross-border risks, manage service providers. Privacy compliance is easier when you own the infrastructure.
  2. CRA (EU): Know what's in your product, track vulnerabilities, report within 24 hours. Supply-chain security is easier when you can audit your own stack.
  3. CIRCIA (US): Detect incidents, report within 72 hours, report ransomware payments within 24 hours. Incident response is faster when you run the system.

Each regime creates obligations. Each regime makes those obligations easier to meet when the organization controls its own infrastructure. Not because the law says "use FOSS" or "self-host" — the laws are technology-neutral. But because the operational practices the laws require — detection, documentation, response, reporting — are structurally simpler when you don't have to coordinate with a vendor to perform them.

September 2026 is when two of these three regimes go live. The third (Bill C-36) is still in Parliament. But the direction is consistent across jurisdictions: incident reporting is mandatory, the clocks are short, and the organizations that can respond fastest are the ones that control their own infrastructure.

What to Do Now

If you operate critical infrastructure — even small-scale, even community-level:

  1. Know whether you're covered. Check the 16 critical infrastructure sectors. A rural water system is covered. A community clinic is covered. A fire hall's communication system may be covered depending on how it's classified. CISA's final rule will clarify thresholds, but assume coverage until you can confirm otherwise.

  2. Build a detection pipeline. If you don't have monitoring, start with the basics: log aggregation, alerting on failed authentication, alerting on unusual network egress. FOSS tools: Prometheus + Alertmanager for metrics, Loki or journald for logs, Wazuh for SIEM. The goal is to know within hours, not days, that something is wrong.

  3. Write an incident response plan. Not a 50-page document. A one-page runbook: who detects, who decides, who reports, how to reach CISA, what information to include. The plan exists so that when the clock starts, you're executing, not designing.

  4. Test ransomware recovery. Offline backups. Tested restoration. The 24-hour payment reporting rule exists because paying ransoms is common. Make it unnecessary in your case.

  5. Document your stack. SBOM for your infrastructure. What software, what versions, what dependencies. The CRA requires this for product manufacturers. CIRCIA doesn't explicitly require it for infrastructure operators — but you can't report what systems were affected if you don't know what systems you have.

The Bottom Line

September 2026 is the month when incident reporting stops being voluntary on both sides of the Atlantic. The EU has a 24-hour vulnerability clock. The US has a 72-hour incident clock and a 24-hour ransomware clock. Both clocks start when you become aware. Both require you to tell a regulator what happened, what's affected, and what you're doing about it.

The organizations that meet these deadlines are the ones that detect incidents themselves, assess them from primary evidence, and respond with their own hands. That describes community-owned infrastructure. It does not describe vendor-dependent infrastructure, where detection is secondhand, assessment is outsourced, and response is a support ticket.

Two continents. One month. Same message. Know what you run.

Sources: CISA expects final CIRCIA rule in September (ExecutiveGov, July 8 2026), Federal News Network — CIRCIA and other cyber rules expected this fall, Unified Agenda — RIN 1670-AA04, EU CRA reporting obligations, CISA CIRCIA town halls 2026, Cyble — 2026 compliance deadlines