The EU's 24-Hour Vulnerability Clock Is Now Law: What the Cyber Resilience Act Means for a Self-Hosted PaaS Sold Commercially

On September 11, 2026 — three days ago — the most operationally demanding part of the EU Cyber Resilience Act switched on. Any company placing a product with digital elements on the EU market must now file an early-warning notification within 24 hours of learning that a vulnerability in its product is being actively exploited, follow it with a detailed notification within 72 hours, and deliver a final report within 14 days of a fix.

Miss the clock and the fine is up to 15 million euros or 2.5% of worldwide turnover. That is not a proposal, a draft, or a transition period. It is applicable law as of this week, a full 15 months before the rest of the regulation applies in December 2027.

Here is the whole obligation in one table, because this is the artifact the rest of the post unpacks:

The question this post answers is the one every small company selling open-source infrastructure software is asking right now: does "manufacturer" mean us — a team shipping an Apache-2.0 self-hosted PaaS — and if so, what exactly has to be standing by Monday morning? The short answer is that the open-source carve-out almost certainly does not cover you once money changes hands, the shipped software counts even though a pure hosted service would not, and the hard part is not the paperwork but the 24-hour detection-to-filing pipeline most small teams have never had to build.

The three clocks, precisely​

Article 14 of Regulation (EU) 2024/2847, in force since December 2024, is the provision that just became applicable. It covers two trigger events: an actively exploited vulnerability in your product, and a severe incident impacting its security. Note the qualifier — you are not reporting every CVE that mentions a dependency you ship.

The clock starts when you become aware that a vulnerability is being actively exploited, or that a severe incident has occurred. That awareness standard is doing a lot of quiet work: it rewards having detection and triage that can reach a verdict fast, and it punishes the "we saw the report on Friday and scheduled a look for next sprint" posture.

The filing mechanics are deliberately single-window. You report once through ENISA's Single Reporting Platform (SRP), which went live alongside the obligations, and the notification goes to the national CSIRT where you have your main establishment while being made available to ENISA simultaneously. No pre-registration dance across 27 member states, and member states like Ireland have published fallback addresses that may only be used when ENISA officially declares the platform offline. The form asks for product type, category, and an overview of the vulnerability or incident — straightforward fields that become very hard to fill accurately at hour 23 if nobody owns the answers.

Two duties ride alongside the regulator filing and are easy to miss. First, manufacturers must also inform affected users of the vulnerability or incident and, where necessary, tell them which mitigations and corrective measures they can deploy themselves. The regulator clock and the user-notification duty run in parallel — you cannot satisfy Article 14 by filing quietly and patching silently.

Second, the final report is not a formality: for vulnerabilities it is due within 14 days of a corrective or mitigating measure becoming available, which means your patch release process now has a regulatory tail. Ship the fix, then owe the root-cause analysis within two weeks.

The penalty deserves its own sentence because it is already live. Breaching the reporting obligations from September 11, 2026 can draw an administrative fine of up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher — the same maximum that will attach to the essential cybersecurity requirements when full application begins on December 11, 2027. For a small vendor the percentage limb is the relevant one, and "small" is no defense: the regulation applies regardless of where the manufacturer is based, as long as the product is made available on the EU market.

Are you a "manufacturer"? The Apache-2.0 scoping question​

This is the section that decides whether the rest of the post is your problem. The CRA's open-source treatment has three tiers, and where you land depends on commercial activity, not license text.

Tier one: open-source software developed or supplied outside a commercial activity is out of scope. A maintainer publishing an Apache-2.0 project in their spare time, with no product on the EU market in the course of a business, should not be worried — that is the consistent reading from the Commission through the OpenSSF's guidance. Tier two: the regulation's novel "open-source software steward" category — foundations and maintainers who systematically support widely-used components — carries a lighter, tailored set of duties, including its own reporting obligations that apply only from December 2027. Tier three, and this is the one that bites: where free and open-source software is placed on the market in the course of a commercial activity, the company responsible qualifies as a manufacturer and inherits the full manufacturer obligations — including the 24-hour clock that started this week.

"Commercial activity" is broader than "selling licenses." Offering the software as a paid hosted service, selling support contracts or commercial editions around it, or monetizing it in a way that places the product on the EU market all point toward manufacturer status. The Apache-2.0 license on your repository does not travel with the product as a shield; the exemption attaches to how the software is supplied, not to the license header.

If bex is merely published as source, it sits in tier one. The moment a company sells it, hosts it commercially, or wraps it in paid support, that company is manufacturing a product with digital elements for CRA purposes. There is no revenue threshold that keeps a small vendor out.

Now the honest caveat, because the scope analysis cuts both ways. Standalone SaaS is out of scope: the Commission's March 2026 draft guidance explicitly confirms that pure cloud and SaaS offerings are not products with digital elements, except where a cloud component qualifies as a "remote data processing solution" without which the product cannot fulfill a core function. Cloud services as services are NIS2 territory, not CRA territory.

That sounds like an escape hatch for a PaaS company — until you notice it only covers the hosted-service side. A self-hosted PaaS is distributed as software that customers install on machines they own. That shipped software — the control plane, the CLI, the installable product — is a product with digital elements placed on the EU market whether or not you also run a hosted version of it.

The company that sells or commercially supports the self-hostable distribution is a manufacturer for that distribution, full stop, while its purely hosted offering answers to a different directive. Both regimes can touch the same company through different artifacts, which is exactly why "we're SaaS, we're exempt" is a dangerous half-reading for anyone whose product also ships as code.

The two obligations riding with the clock: SBOM and five-year support​

The reporting clock gets the headlines, but two companion duties determine whether you can actually meet it — and both need infrastructure built before the first CVE, not during it.

The first is the software bill of materials. Manufacturers must be able to produce a machine-readable SBOM covering their product's components — in practice SPDX or CycloneDX — and hand it to market surveillance authorities on request, under confidentiality. The SBOM is what turns "Log4Shell-style library X has an actively exploited flaw" into "here are the exact product versions and releases containing X" inside the 24-hour window.

A team that assembles its dependency inventory by hand during an incident has already lost the clock; a team that generates a signed SBOM per release in CI walks into hour zero with the answer half-written. Note the direction of travel: vulnerability handling must be documented and auditable, with a paper trail a buyer is entitled to ask about. Procurement questionnaires in the EU will soon ask for your SBOM posture the way they ask for SOC 2 today.

The second is the support period. Vulnerability-handling duties — identifying and documenting vulnerabilities, shipping security patches — must be honored for the product's expected lifetime or at least five years from placing on the market. Five years is the floor, not the ceiling: if your PaaS release is the kind of thing customers run for a decade, your declared support period should say so.

Buyers are now advised to check whether the declared period matches actual expected use rather than defaulting to the minimum. Concretely, this means every release needs a published support window, a patch channel that outlives your enthusiasm for old versions, and a vulnerability-handling process that survives staff turnover. "We support latest only" is a support-period statement — but only if it is written down, communicated, and consistent with a five-year minimum commitment on the product's security maintenance.

What breaks first in a small OSS company​

Large vendors will meet the 24-hour clock with headcount: a product-security team, an on-call rotation, a pre-existing CSIRT relationship. A small open-source company meets it with automation or not at all, and three gaps tend to break first.

The first gap is the awareness-to-filing pipeline. The clock runs from awareness, and awareness in a five-person company usually looks like a maintainer reading a security advisory over coffee. That is fine as a sensor; it is not fine as a process.

Between "someone saw it" and "filed on the SRP" sit triage (is our product affected?), exploitability assessment (is it actively exploited, or theoretical?), scope enumeration (which releases, which SBOM entries?), and drafting (product type, category, impact overview, mitigations for users). Each step needs an owner and a template before the incident, because 24 hours leaves no room to invent them. The single most valuable artifact is a one-page runbook: who decides we are affected, who drafts the filing, who approves user notification, and who actually clicks submit on the Single Reporting Platform.

The second gap is release archaeology. When the exploited component is three transitive dependencies deep in a container image you built eight months ago, "which releases contain it" is an SBOM query — if SBOMs exist per release — or a forensic dig through old Dockerfiles and lockfiles if they do not. This is the concrete reason SBOM generation belongs in the release pipeline now, alongside signing and provenance: it converts the hardest 72-hour-notification question into a database lookup. Generate it at build time, store it per release, and make sure the incident runbook says where it lives.

The third gap is the support-period declaration nobody wrote. Teams that have always patched "whatever is current" discover during their first filing that the form and the follow-up questions assume a defined support posture: which versions get patches, for how long, through what channel. Publishing that statement — versions, dates, patch channel, end-of-life policy — is an afternoon's work that cannot be credibly backdated mid-incident. Do it this week, while the only clock running is the regulatory one and not your own.

The stand-it-up-now checklist​

If the outline above reads as a lot, it compresses to five actions, ordered by how badly they hurt to improvise:

1. Name the filing owner. One person (plus a deputy) owns SRP submissions: they know which national CSIRT is yours, have access to the Single Reporting Platform, and can reach whoever approves external disclosure. Write the names in the runbook.
2. Run a 24-hour fire drill. Take a recent CVE in your dependency tree, real or hypothetical, and time yourselves from "advisory lands" to "draft early-warning complete." If it takes longer than a working day with everyone cooperating, the process — not the people — needs fixing.
3. Wire SBOM generation into the release pipeline. Emit SPDX or CycloneDX per release, store it next to the artifacts, and verify you can answer "which releases contain library X at version Y" in minutes. Backfill at least the currently supported releases.
4. Publish the support-period statement. Supported versions, patch channel, lifecycle dates, and the five-year-minimum commitment in writing, somewhere customers and market surveillance can find it.
5. Document the vulnerability-handling process. Intake, triage SLA, exploitability criteria, patch-and-disclose workflow, user-notification templates. This document is both your runbook and the auditable paper trail procurement will ask for.

None of these require a compliance department. All of them are dramatically cheaper than a first filing done from scratch at hour 20 — or a fine whose percentage limb does not care how small the undertaking is.

The clock is the warm-up; December 2027 is the exam​

Keep the reporting obligations in proportion: they are the CRA's early wave, deliberately staged 15 months ahead of full application. On December 11, 2027 the whole apparatus lands — essential cybersecurity requirements designed in from the start, conformity assessment with CE marking, technical documentation retained for a decade, and the steward-tier reporting duties for the open-source foundations underneath your stack. The conformity-assessment bodies that will judge all of it started being designated this June. What just switched on is best understood as a forcing function: the EU gave manufacturers the incident-reporting muscle to build first, because a vendor that cannot file in 24 hours in 2026 will not be ready for secure-by-design conformity in 2027.

For a self-hosted PaaS sold commercially, that sequencing is almost gentle. The product is already yours to patch, the SBOM is generatable from your own build, and the support window is yours to declare. The teams that will struggle are the ones that treat September 2026 as someone else's deadline — a problem for device makers and IoT vendors — while shipping installable software into the EU market every week. If that sentence describes you, the checklist above is your September.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.