The EU Cyber Resilience Act Is Here: How Agencies Must Track SBOMs and Dependencies

Article image
The EU Cyber Resilience Act Is Here: How Agencies Must Track SBOMs and Dependencies
On September 11, 2026, the first hard deadline of the EU Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847 — arrives. Under Article 14, manufacturers of "products with digital elements" made available on the EU market must report actively exploited vulnerabilities and severe security incidents to their national CSIRT and the European Union Agency for Cybersecurity (ENISA), starting with an early warning within 24 hours of becoming aware.

This date has been circled on compliance calendars for over a year, but it catches most web agencies off guard for a specific reason: the CRA's headline design and documentation requirements don't apply until December 11, 2027. Article 14 reporting is the exception — it applies more than a year earlier, and it applies to products already sitting on the market today, not just new builds.

For agencies that build and maintain custom sites, client portals, and CMS extensions touching EU users, this raises a genuinely operational question: which of that work is actually in scope, and what do you need in place before Friday?

What Article 14 Actually Requires
Article 14 creates two reportable triggers: an actively exploited vulnerability in a product with digital elements, and a severe incident affecting that product's security. Routine bugs, patches, and vulnerabilities that haven't been exploited in the wild are explicitly out of scope — this is not a "report every CVE" regime.

Once a manufacturer becomes aware of a qualifying event, three deadlines follow:

Milestone Deadline What's Required
Early warning Within 24 hours Identify the affected product and initial status via ENISA's Single Reporting Platform
Detailed notification Within 72 hours Fuller assessment of severity, impact, and initial mitigation
Final report 14 days after a fix is available (vulnerabilities) / 1 month after the 72-hour notice (incidents) Root cause, description, and remediation details
A few clarifications worth knowing before you build a process around this:

The clock starts at "awareness," not at confirmation. You don't get to finish a forensic investigation first — reliable evidence that a vulnerability is being actively exploited starts the 24-hour clock.
There's no retroactive reporting. If you already knew about active exploitation of a vulnerability before September 11, 2026, you don't have to report that specific instance. But if you knew about the vulnerability itself beforehand without knowing it was being exploited, and exploitation is discovered afterward, it becomes reportable.
Legacy products aren't exempt. Article 69(3) extends the Article 14 reporting duty to products with digital elements already placed on the EU market — including sites and software you shipped years ago, if they're still in use.
Does This Actually Apply to Your Agency? The Scope Question Most Draft Guides Skip
This is the part that gets flattened in a lot of CRA content aimed at web agencies, and it matters for deciding how much of your portfolio needs this treatment.

The CRA targets products with digital elements placed on the market — not services. That distinction has real teeth:

Software provided purely as a service (SaaS) is generally excluded. If a client's site or portal is delivered entirely through the browser, with no downloadable or installable component, it's more likely to sit outside CRA product scope and under the adjacent NIS2 directive instead, depending on your client's sector and size.
Downloadable or installable components pull work back into scope. A proprietary WordPress plugin or theme you build and distribute to multiple clients, a mobile app, or any installable software component with a network connection is treated as a product — including the cloud backend it depends on to function.
Custom-built software developed exclusively for one client and not placed on the general market is generally treated differently than a commercialized product, though guidance is clear that bespoke software delivered commercially to paying clients is, as a rule, still in scope for the agency building it — the "internal use only, never commercialized" carve-out is narrow.
Free, non-commercial open-source software is excluded, but that exclusion disappears the moment a company integrates it into a product it sells.
Practically: a marketing site or a browser-only client portal you host and maintain is a weaker CRA case than a plugin, theme, or software component you build once and deploy across many clients. Don't assume either way without checking a given engagement against these lines — and don't assume this replaces a NIS2 assessment if your agency also runs managed hosting or cloud services for clients, since the two regimes sit side by side rather than one excluding the other.

The Platform Manufacturers Are Supposed to Report Through Isn't Fully Built Yet
Here's a fact that didn't exist when earlier drafts of CRA guidance were written: ENISA's Single Reporting Platform (SRP) — the single mandatory channel for all Article 14 notifications — is scheduled to go live on the same day the reporting obligation itself takes effect, September 11, 2026. As of late August 2026, it had not yet been published at a public URL, and ENISA's own FAQ confirms the platform will support only mandatory Article 14/24 reporting at launch, with voluntary reporting deferred to a later phase.

Two practical consequences follow:

There's no dry run. Registration, CSIRT routing, and onboarding materials are being finalized in the days immediately before go-live, so the first time many manufacturers touch the platform may be during an actual report.
It's a manual web portal, not an API. Reports must be filed through the web interface — there's no automated submission pipeline at launch, so even a fully automated internal detection process still ends at a human filing the report.
The takeaway for agencies: the parts of readiness that don't depend on the platform — knowing which CSIRT covers your main establishment, having a documented internal escalation path, and knowing exactly which components and versions run on which client site — are worth having settled now, regardless of when the portal formally opens.

Why Manual Dependency Tracking Breaks Under a 24-Hour Clock
Most agencies never built a system for this because, until now, nothing forced them to. Client portfolios typically track which sites exist, not which package versions and plugins are running underneath them.

That gap becomes a real liability once the reporting clock is running:

A modern site build typically pulls in a long chain of top-level libraries and CMS plugins, each of which brings its own nested sub-dependencies. A vulnerability in one shared, low-level package can affect many client sites at once.
WordPress and Drupal builds commonly run dozens of third-party plugins, several of which may lag behind upstream security patches. When a CVE is disclosed for a plugin version, finding every affected client by manually searching each site can easily blow past 24 hours.
Inherited legacy code and third-party APIs compound the problem — without a record of where a component came from, confirming whether a specific client site is affected is guesswork.
None of this requires exotic tooling to fix. It requires an accurate, queryable record of what's actually installed where.

What Is a Software Bill of Materials (SBOM)?
A Software Bill of Materials is a structured, machine-readable inventory of every component, library, and dependency in a piece of software, plus how those pieces relate to each other — the "ingredient list" for a build. The two dominant standardized formats are CycloneDX and SPDX, and a typical CycloneDX component entry looks like this:

{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "library",
"name": "guzzlehttp/guzzle",
"version": "7.8.1",
"purl": "pkg:composer/guzzlehttp/guzzle@7.8.1",
"licenses": [{ "license": { "id": "MIT" } }]
}
]
}
It's worth separating two related but distinct deadlines: the CRA's formal technical documentation requirements — which include SBOM-related obligations under the essential requirements in Annex I — apply from December 11, 2027, alongside conformity assessment and CE marking. But the practical need for an SBOM arrives far earlier: you can't report an actively exploited vulnerability in a component you don't know you're running, so functional SBOM coverage is a prerequisite for meeting the September 2026 reporting deadline in practice, not a separate 2027 problem.

Generating SBOMs Without Manual Effort
Don't build these by hand — generate them as part of your existing build process:

PHP / Composer projects: the cyclonedx/cyclonedx-php-composer plugin (installed via Composer, run as composer CycloneDX:make-sbom) generates a CycloneDX-format SBOM directly from composer.json/composer.lock.
Node / npm projects: @cyclonedx/cyclonedx-npm generates CycloneDX SBOMs from a project's manifest and lockfile. npm itself now also ships a built-in npm sbom command (npm v9+) that can output either SPDX or CycloneDX format without installing anything extra.
Yarn projects: @cyclonedx/yarn-plugin-cyclonedx covers the equivalent workflow for Yarn.
Wiring one of these into your CI/CD pipeline means every build produces an up-to-date component inventory automatically, rather than relying on someone remembering to run an audit.

A Practical Compliance Framework for Agencies
Automate SBOM generation in your build pipeline using the tools above, so every deployed site has a current, machine-readable inventory rather than a stale manual list.
Establish a single point of contact for vulnerability disclosure. Article 14 assumes manufacturers have a channel — internal or public — for receiving reports from researchers, clients, or monitoring tools, with a clear internal escalation path once something comes in.
Define support lifecycle and patch SLAs in client contracts. Spell out how long your agency provides security patches for custom code, and set a concrete turnaround target for third-party plugin and dependency patches (for example, applying upstream security releases within a defined window).
Confirm your CSIRT routing and register early, rather than waiting to do it for the first time during an actual incident.
Keep a portfolio-wide, per-client record of what's actually installed — CMS core version, active plugins/themes, and key dependency versions — so that when a CVE is disclosed for a specific package, you can check exposure across your whole client base quickly rather than opening each project individually.
Where InstaRenewal Fits — and Where It Doesn't
It's worth being precise here, because this is where a lot of vendor content overreaches: InstaRenewal is a manual renewal-date tracking and asset ownership record-keeping platform for domains, SSL/TLS certificates, hosting accounts, and plugin or software licenses. It is not a vulnerability scanner, an automated SBOM generator, a live threat-monitoring feed, or a CVE-matching engine, and it doesn't submit anything to ENISA's Single Reporting Platform on your behalf.

What it does help with is the unglamorous prerequisite step 5 above depends on: giving your team one place to log, per client, which CMS version, plugin licenses, and software components are in use — populated from the SBOM exports and audits you're already generating — alongside when each license or certificate is due to expire or reach end-of-life. When a CVE lands for a library or plugin your agency maintains across several client builds, having that inventory centralized and searchable means you're checking one record instead of digging through dozens of separate repositories or spreadsheets to figure out who's affected. It's the record-keeping layer under your compliance process, not the detection or reporting layer — those still require the SBOM tooling above and a human filing through ENISA's portal.

Conclusion
The September 2026 deadline is narrower than the December 2027 headline requirements, but it's also less forgiving: a 24-hour clock, a reporting platform still being finished, and a scope question — SaaS versus product, bespoke versus commercialized — that's easy to get wrong in either direction. Agencies that sort out which of their work is actually in scope, wire up automated SBOM generation, and keep an accurate, centralized record of what's running where will find September 11 a lot less eventful than agencies still relying on memory and scattered spreadsheets.