EU Cyber Resilience Act reporting has started, and your mainframe is in scope

← All posts

On 11 September 2026, the reporting obligations in Article 14 of the EU Cyber Resilience Act began to apply. Most compliance planning inside large enterprises has been anchored on 11 December 2027, the date the Act applies in full. That date is real, but it is not the first one, and organisations that planned around it have already missed a live obligation.

The part that matters most for anyone running a mainframe is scope. Article 14 does not apply only to products designed after the Act came into force. It reaches products with digital elements that were placed on the EU market before the Act applies in full. Software shipped in 2015 is in scope. So is software compiled in 1994 and still running a general ledger.

This post covers what the obligation actually requires, why legacy estates are the difficult part of meeting it, and what work has to happen on COBOL, PL/I and Assembler code before a reporting process can function at all.

What Article 14 requires, precisely

The Cyber Resilience Act entered into force on 10 December 2024. Its main obligations, covering essential cybersecurity requirements, conformity assessment, technical documentation and CE marking, apply from 11 December 2027. Article 14 runs ahead of that.

From 11 September 2026, a manufacturer of a product with digital elements must notify actively exploited vulnerabilities and severe incidents affecting the security of the product. The cascade is defined:

Notifications go through the single reporting platform operated by ENISA, addressed to the CSIRT of the member state where the manufacturer has its main establishment, with the information made available to ENISA and relevant national CSIRTs.

The retroactivity clause is the one to read

Article 69(3) is the provision that pulls legacy systems in. The Article 14 reporting duties apply to products with digital elements that were placed on the market before the date of full application. A manufacturer cannot argue that an older product predates the regime.

For a bank, insurer or logistics operator with a mainframe estate, this changes the shape of the problem. The obligation is not limited to the customer-facing web application built last year. If a mainframe-hosted component forms part of a product made available on the EU market, and an actively exploited vulnerability is identified in it, the clock starts.

What “manufacturer” covers

The Act is written around products with digital elements made available on the EU market in the course of a commercial activity. Software supplied to customers, embedded in a device, or sold as part of a service offering falls inside more often than teams expect. Purely internal systems that are never made available as a product sit differently, which is exactly why the scoping exercise has to be done deliberately rather than assumed.

That scoping decision is a legal one and belongs with counsel. The engineering consequence is the same either way: you cannot decide what is in scope without an accurate inventory of what your systems contain.

Why legacy estates are where this gets hard

Reporting within 24 hours assumes three capabilities. You know what components your product contains. You can determine whether a disclosed vulnerability affects any of them. You can assess whether it is being actively exploited in your product specifically.

On a modern application stack, tooling exists for all three. On a mainframe estate with four decades of accumulated code, each one has a gap.

You cannot produce a bill of materials for code nobody can parse

Software bills of materials are built by tools that understand package manifests. A COBOL estate has no manifest. Its dependencies are expressed as copybooks pulled in at compile time, static link edits, load modules bound years ago, calls into vendor libraries whose licence records outlived the people who bought them, and Assembler routines whose source may or may not still exist.

Compiling an inventory of that estate is an analysis problem, not a scanning problem. It requires parsing the source as the compiler parses it, resolving the copybook chains, following the call graph across programs and languages, and reconciling what is in source control against what is actually running.

Teams that have never done this are consistently surprised by three findings: the number of load modules with no matching source, the number of copybooks that exist in multiple versions with the same name, and the number of programs nobody can attribute to an owning application.

Exploitability assessment needs a call graph

The difference between a vulnerability present in your estate and a vulnerability that is exploitable in your product is reachability. A flaw in a routine that no live path invokes is a different disclosure than one sitting on the transaction path.

Answering that question inside a 24 hour window requires a dependency and call graph that already exists. Building it during an incident is not feasible. This is the single strongest argument for doing analysis work now, while nothing is on fire.

Undocumented behaviour is not the same as undisclosed behaviour

The Act pushes toward knowing what your product does. A large share of mainframe estate behaviour lives only in the code, with the original design documents lost, superseded or never written. Regulators do not accept institutional memory as documentation, and the people holding that memory are retiring. We covered that demographic pressure separately in the legacy code talent shortage.

Practical sequence for a mainframe estate

The work divides cleanly. None of it requires committing to a migration.

Establish the inventory

Start with a complete, machine-produced inventory: programs, copybooks, load modules, JCL, subsystem definitions, database access, external interfaces and the languages present. On most estates this produces a list materially different from the one the organisation believed it had.

The point is not tidiness. The inventory is the artefact every later step reads from.

Build the dependency and call graph

Once programs parse, the call relationships can be resolved: static calls, dynamic calls resolved through variables, CICS LINK and XCTL, batch job step sequencing, database and file access by program. This is the structure that answers reachability questions under time pressure.

Dynamic call resolution is the part that separates real analysis from a grep. A CALL WS-PROGRAM-NAME tells you nothing on its own. Determining the possible values of that variable requires data flow analysis across the program.

Reconcile source against production

Every estate has drift. Load modules running in production without corresponding source, source in the library that was never promoted, and emergency fixes applied to one environment. A reporting obligation that rests on an inventory of source you cannot prove is running is an obligation you cannot actually meet.

Locate the security-relevant surface

Not every program carries the same exposure. Identify what handles external input, what performs cryptographic operations, what touches authentication and authorisation, and what sits on a network-facing path. That subset is where analysis depth should concentrate, and it maps directly to the prioritisation logic regulators and buyers use elsewhere.

Define the process before you need it

A 24 hour window is an operational commitment, not a technical one. Someone has to be reachable, someone has to make the call on whether the product is affected, and someone has to file. Engineering supplies the evidence; the process has to exist independently.

Where code transformation fits

Compliance work and modernisation work are usually presented as competing for the same budget. On a mainframe estate they overlap more than they compete, because both depend on the same foundation.

Analysis is the shared asset

The inventory, call graph and dependency map required for CRA readiness are the same artefacts a migration assessment produces. Organisations that build them for compliance reasons find they have already paid for the hardest part of modernisation scoping. Organisations that build them for a migration find they have a compliance capability as a by-product.

This is why we treat analysis as an engagement in its own right rather than a phase inside a migration. Understanding the estate has value whether or not the code moves. The techniques are described in how deterministic software transformation works.

Reducing surface reduces obligation

Dead code carries the same reporting exposure as live code if it ships inside the product. Estates routinely carry programs that no job invokes and copybooks no program includes, because deleting them was never anyone’s priority and nobody could prove they were safe to remove.

Compiler-grade analysis can prove it. Removing genuinely unreachable code is one of the few changes that reduces compliance surface, defect surface and build time simultaneously, without altering any behaviour the business depends on.

Comprehension debt is compliance debt

The reason a 24 hour assessment is frightening on a legacy estate is that nobody is confident what the code does. That is a comprehension problem before it is a security problem, and it is addressable directly through business rule and structure extraction rather than through a platform change.

What December 2027 adds

The September obligation is reporting. The December 2027 date brings the rest: essential cybersecurity requirements in Annex I, conformity assessment, technical documentation and CE marking.

Several of those requirements press harder on legacy code than the reporting duty does. Products must be designed and developed without known exploitable vulnerabilities and with a minimal attack surface. They must ship in a secure default configuration. They must support secure software updates throughout the defined support period.

A mainframe application that can only be patched through a change window measured in weeks, built by a team of three, using a compiler version that left standard support years ago, will struggle against the update requirement specifically. The gap between now and December 2027 is the window to address that, and the work involved is ordinary modernisation work: currency, structure, test coverage and deployment capability.

What a component inventory looks like on a mainframe estate

Teams asked to produce a bill of materials for a mainframe application usually start by looking for a tool and stop when they find none. It is more useful to start from what the inventory has to contain.

The component classes that have to be enumerated

Nothing on that list is produced by a package manifest scan, which is why conventional software composition analysis returns an empty or misleading result on this estate.

Reconciliation is the step that produces the surprises

An inventory derived from source libraries describes what the organisation intends to be running. An inventory derived from load libraries describes what is actually running. The difference is where the reportable risk sits.

Three reconciliation findings appear on almost every estate. Load modules with no corresponding source, which cannot be recompiled and therefore cannot be patched conventionally. Source that exists in the library but was never promoted, meaning the version under change control is not the version in production. And multiple copybooks with the same name in different libraries, where which one a program picked up depends on the concatenation order in the compile JCL.

That last one is worth dwelling on. Two programs including a copybook by the same name can have compiled against different definitions, years apart, and nothing in either program’s source records which. Establishing the actual definition each program uses requires reproducing the compile-time concatenation rather than reading the source.

Who does what when the clock starts

The twenty-four hour window is an organisational commitment before it is a technical one, and the most common gap is not tooling but ownership.

The decisions that have to be made under time pressure

Someone has to determine whether a disclosed vulnerability affects a component present in the product. Someone has to determine whether the affected code path is reachable in the product as shipped. Someone has to determine whether exploitation is active rather than theoretical. And someone has to decide that the threshold for notification has been met and file it.

Those are four different judgements, and in most organisations they sit with four different functions: security operations, application engineering, threat intelligence and legal or compliance. If the routing between them is established during the first incident, the window is gone.

What engineering owes the process

Engineering’s contribution is evidence, prepared in advance: the inventory, the dependency graph, the reachability position for security-relevant components, and a named owner per application who can be reached out of hours. None of that can be produced inside the window.

The rehearsal argument

Organisations that run a tabletop exercise against a hypothetical advisory affecting a mainframe component consistently find the same two gaps: nobody is certain which product the component ships inside, and nobody can establish reachability quickly. Both are fixable, and both are considerably cheaper to fix before they matter.

Three estate shapes and what each should do first

The right first step differs by how the estate is structured, and the distinction is worth making because generic compliance advice fits none of them well.

The estate with good source control and poor documentation

Source is complete and under management, and nobody knows what the programs do. The binding constraint is comprehension rather than inventory. The first step is dependency and call graph extraction, followed by rule location in the security-relevant subset.

The estate assembled through acquisition

Several formerly independent estates, different conventions, different compiler versions, overlapping copybook names, and in some cases genuinely unknown ownership boundaries. The binding constraint is attribution: establishing which application each component belongs to and which product it ships inside. Inventory first, comprehension second.

The estate with substantial vendor content

A large proportion of the running code came from third parties, some of whom no longer exist. The binding constraint is that reporting obligations attach to the product you place on the market regardless of who wrote the code inside it. The first step is a vendor component register with current support status, because unsupported third-party components are the exposure you can neither patch nor easily replace.

What counts as evidence

Compliance conversations turn on what can be shown rather than what is known, and legacy estates fail on that distinction more often than on the underlying facts.

Generated beats asserted

An inventory produced by parsing source and reconciling against production can be regenerated on demand, dated, and shown to differ or not differ from the previous version. An inventory maintained in a spreadsheet by someone knowledgeable cannot be defended the same way, because its accuracy rests on a person rather than a process.

The practical implication is to prefer artefacts that are derived rather than curated, even when the curated version is currently more accurate. Derivation is what makes the artefact repeatable, and repeatability is what an assessor tests.

Reachability is the answer to the only question that matters quickly

The question in an incident is not whether a component is present but whether it is reachable in the product as shipped. An organisation that can answer that from an existing call graph, in an hour, is in a completely different position from one that has to read code.

Building the graph in advance also converts an emergency judgement into a documented one, which matters because the reporting decision will be reviewed afterwards.

Version evidence closes the loop

Knowing which source produced which running module is what allows you to state, with support, that a disclosed defect in a component either is or is not in your product. Estates with unreconciled drift between source and load libraries cannot make that statement, and the gap is not visible until it is tested.

The documentation gap is a code problem

Where a system’s behaviour exists only in the source, documentation cannot be produced by interview. It has to be extracted. That work has a value well beyond the regulation, because it is the same output that reduces key person concentration and makes any later change cheaper.

The fifteen month window

Between the reporting obligation that started in September 2026 and the full obligations arriving in December 2027 sits roughly fifteen months. That is a useful planning unit.

It is long enough to run inventory, reconciliation and dependency analysis properly, to establish the reporting process and rehearse it, and to address the currency positions that make the update requirement difficult to meet.

It is not long enough to do that work twice, which is the argument for deriving the artefacts in a form that serves both the September obligation and the December 2027 requirements rather than treating them as separate programmes.

The organisations that will find the second date manageable are the ones using this window to build a picture of the estate they do not currently have. The ones that will not are the ones treating September as an event that has passed.

A readiness test you can run this week

Article 14 is a capability question, not a paperwork question. Five checks establish whether the capability exists, and each one has a verifiable answer rather than an opinion.

Organisations we work with typically pass checks four and five and fail the first three, which is the opposite of what their compliance documentation implies. The documentation describes the process; the failing checks describe whether the process can be fed.

Scoring it honestly

Three or fewer passes means the reporting obligation is currently theoretical: the process exists on paper and cannot produce an answer inside the window. Four passes means the gap is narrow and specific. Five means the remaining work is rehearsal rather than construction.

The useful property of this test is that it is falsifiable. “We are working toward CRA readiness” is not a status. “We can enumerate components and cannot establish reachability” is, and it points at exactly one piece of work.

Common questions

Does the CRA apply to systems we only use internally?

The Act is framed around products with digital elements made available on the market in the course of a commercial activity. Purely internal systems generally sit outside that framing, but the determination depends on how the software reaches customers and should be made with counsel rather than assumed by the engineering team.

We are not an EU company. Does this reach us?

The trigger is the EU market, not the location of the manufacturer. Products made available on the EU market are in scope regardless of where the manufacturer is established.

Our mainframe code has not changed in fifteen years. Does that help?

No. Article 69(3) applies the reporting duty to products placed on the market before the Act applies in full. Age does not create an exemption.

Can we generate an SBOM for COBOL?

Not with conventional scanning tools, which read package manifests that do not exist here. A component inventory for a COBOL estate has to be derived by parsing the source, resolving copybook chains and following the call graph, then reconciled against what is actually running in production.

Do we have to migrate off the mainframe to comply?

No. Nothing in the Act requires a platform change. What it requires is knowing what your product contains, being able to assess exploitability quickly, and being able to ship a fix. All three are achievable on z/OS.

Where do the fines sit?

Administrative penalties under the Act reach up to 15 million euro or 2.5 percent of worldwide annual turnover for the most serious infringements, with lower ceilings for other categories and specific limitations for micro and small enterprises. The exact exposure depends on the infringement category, which is another reason to involve counsel in scoping.

What is the difference between the September 2026 and December 2027 dates?

September 2026 brings the Article 14 reporting duties for actively exploited vulnerabilities and severe incidents. December 2027 brings the main obligations: essential cybersecurity requirements, conformity assessment, technical documentation and CE marking. The first is operational, the second is structural.

Which CRA requirement is hardest for a mainframe estate?

Usually the secure update requirement arriving in December 2027. An application that can only be patched through a change window measured in weeks, maintained by a small team, compiled under a version that left standard support years ago, struggles against an obligation to ship security updates through the defined support period.

Does an inventory built in a spreadsheet satisfy this?

It may be accurate and it is hard to defend, because its accuracy depends on a person rather than a process. Artefacts derived by parsing source and reconciling against production can be regenerated, dated and compared against the previous version, which is what an assessor tests.

Where should an organisation with no inventory start?

With component enumeration and source-to-production reconciliation, in that order. Everything else, including reachability and the reporting process itself, reads from those two artefacts, and neither can be produced inside an incident window.

The practical position

The reporting obligation is live now. The full requirements arrive in December 2027. Between those two dates sits roughly fifteen months, which is enough time to do the inventory and analysis work properly and not enough time to do it twice.

The organisations that will find this manageable are the ones that already know what their estate contains. For everyone else, the first step is not a compliance programme. It is an accurate picture of the code.