The EU Will Make You Report What It Hasn't Yet Made You Fix

In eleven days, on September 11, manufacturers of products with digital elements sold into the European Union have to tell a regulator within 24 hours of learning that a vulnerability in one of their products is being actively exploited, with a fuller account due at 72 hours.

I have a decent idea what the next eleven days look like inside most of those companies, having spent close to thirty years watching software organizations get ready for a date on a calendar. There will be a spreadsheet of products and owners that somebody builds over a weekend, a notification template that goes to legal for review, probably a consultant on a two-week engagement. It will mostly work. By September 10, the majority of them will be able to file inside 24 hours, and they will be right to feel relieved about it, because filing on time is exactly what the regulation asks, and it is not a trivial thing to arrange. What I would gently point out is that almost none of them will come out of the exercise able to answer the underlying question any faster than they can today.

Look at the two dates

The reporting obligations take effect September 11, 2026. The requirements that actually govern how a product gets designed and built, what the regulation calls the essential cybersecurity requirements, do not apply until December 11, 2027. That is fifteen months apart, and the reporting requirement is the one that comes first.

So for fifteen months, European regulators will require manufacturers to disclose exploited vulnerabilities in products that are not yet subject to the regulation's own engineering requirements. Companies will have to report these problems before they are required to have done anything to prevent them.

I do not think that is an accident, and it is certainly not a drafting mistake. Mandating disclosure costs a regulator almost nothing, and it becomes very hard to fake once thousands of companies are doing it at once. Within a year it will tell Brussels more about the real condition of software sold in Europe than a decade of vendor self-attestation ever did. The regulation is taking inventory before it starts inspecting, which is what you would do if you actually wanted to find out how bad things were. So what arrives on September 11 is a visibility requirement rather than a security one, and a lot of people who ought to know the difference are treating them as the same thing.

What the countdown will expose

The companies that struggle after September 11 will not be the ones carrying the most vulnerabilities, because every company of any size is carrying a great many vulnerabilities and always has been. The ones that struggle will be the ones that cannot say, on demand and without convening a working group, what shipped in a given product and when somebody first knew there was a problem with it.

That inability is not new, and it has been survivable for years, because nothing ever forced anyone to demonstrate it in writing, to a regulator, on a 24-hour turnaround. What changes in eleven days is that the gap starts getting documented by the company itself, with dates on it, and filed somewhere official.

I want to be fair to the people who run these programs, because the incentives have been genuinely awful for a long time. Nobody has ever been promoted for maintaining a standing record of what ships inside their products. The work is unglamorous, it never finishes, and there is no launch date attached to it. Buying a scanner two weeks out from a deadline, on the other hand, is fast and visible and answers the board's question in a satisfying way. Of course that is what most organizations have optimized for. We spent a decade building security tooling around the moment of detection and almost nothing around the far duller question of whether anyone can reconstruct what we knew and when we knew it.

None of this should be news

Something close to this has happened four or five times over the course of my career, and the shape is familiar enough now that I can usually place an organization in the cycle within ten minutes of conversation.

Sarbanes-Oxley did it in 2002, when the accuracy of a financial statement stopped being something the accounting department handled and became something a CEO and a CFO signed their own names to. GDPR did it in 2018, with a 72-hour breach notification requirement that made "we are still looking into it" an insufficient answer for the first time. The SEC did it again in 2023, when public companies became obliged to disclose material cybersecurity incidents within four business days of concluding they were material, which took a technical judgment call and quietly relocated it into the disclosure committee.

What follows tends to go the same way each time. There is a scramble, and it works. Then a year or two goes by in which everyone slowly discovers that complying with the rule and fixing the underlying problem were separate projects all along, and only one of them got funded. Then, usually after something embarrassing happens, the operational change finally occurs that should have happened before the regulation existed.

So I am less interested in whether your organization makes the September 11 deadline, since most will. What I find worth asking is why it keeps arriving as news. The Cyber Resilience Act entered into force on December 10, 2024, which means twenty-one months will have passed between the law entering into force and the reporting obligation taking effect, all of it published, with the dates attached. If your company is scrambling this month, that is itself the useful piece of information, because it means the regulation got tracked by legal and never handed to anyone in a position to turn it into engineering work.

The question boards are asking

Most of what gets written about the CRA is aimed at security engineers and concerns reporting mechanics, which makes sense, since that is where the immediate work lives. The conversation I think matters more is happening in board meetings, and it is going badly in a way that is easy to miss, because it sounds responsible while it is happening.

Boards are asking their CISOs some version of "will we be compliant on September 11." It is a fair question and I understand why it gets asked, but it is close to useless, because the answer is almost always going to be yes. Filing a notification inside 24 hours is achievable for any organization willing to put enough people on it for two weeks, and a yes tells the board essentially nothing about what the company is actually exposed to.

I would rather hear a board ask whether the company can establish what is in a given product, and when it first knew about a vulnerability in it, right now, today, without standing up a special project to go find out.

If the answer comes back with a caveat, or a timeline, or the name of a person who would have to go and check, then the company does not have that capability. What it has is a few people who are good at producing the answer under pressure, which is a real asset but a fragile one, and it does not survive their resignation or two incidents landing in the same week.

I sit in board rooms and I sit in engineering reviews, and what I see coming is the same shift that followed Sarbanes-Oxley, where the responsibility ended up with a name attached to it. A director who accepts "we will be compliant" is accepting a status report on a filing process, when what they needed was an honest assessment of a capability, and when that difference eventually matters, it is going to matter to the director rather than the CISO.

The excuse is getting an upgrade

For most of the past decade the standard answer to a hard question about software supply chain was "we had a scanner." That was a real answer and it meant something, in that somebody had bought a tool and pointed it at the codebase. What it never established was whether anybody acted on what came out, how quickly they acted, or whether the finding ever reached a person with the authority to stop a release.

After September 11 that answer gets a newer version, which is "we filed a report." That will also be true, and it will establish about as much.

A scanner tells you a vulnerability exists. A report tells a regulator you knew about it. What neither one tells you is whether your organization can do anything about it, this week or next quarter, or whether you are any better placed for the next regulation, which is already being drafted somewhere by people who will have read the disclosures this one produces. That last capability, being able to act on what you know, is the only one of the three that has ever reduced anybody's risk. It is also the only one that cannot be bought in eleven days, which is presumably why it keeps losing the budget argument.

What permanent looks like

I am not going to close with a checklist for the next eleven days. Plenty of good ones exist, and a checklist is more or less the shape of thinking that produces this situation every time.

Tooling is not what separates the organizations that come through these transitions well. They are the ones that treat knowing what is inside their software as a standing operational capability, funded continuously and owned by somebody, in the same way they already treat knowing what is on their balance sheet. Nobody assembles a general ledger in a panic because a filing date is coming up. That we still do the equivalent with software provenance is something we have chosen, and we could choose otherwise, because nothing technical is stopping us.

At ActiveState, we think provenance belongs in the build itself rather than in a report assembled afterward. That is a slower thing to put in place than anything anyone can sell you in the next eleven days.

September 11 will come and go, and most companies will file on time and move on to the next thing. The ones that spend the next eleven days on a harder question than "will we be compliant" are the ones that will not be having this conversation again in December 2027, when the requirements about how the software actually gets built finally arrive. Fifteen months is not very long, and that is the deadline I would be planning against.

About the Author: Abby Kearns is CEO of ActiveState and a technology executive with more than 25 years of experience building and scaling enterprise software organizations. She previously served as CTO of Puppet, where she helped lead a strategic transformation culminating in the company's acquisition by Perforce Software. Earlier in her career, she was CEO of the Cloud Foundry Foundation, guiding the growth of one of the industry's largest open source cloud platform ecosystems. Abby currently serves on the board of Akka (formerly Lightbend). She is known for helping companies translate major shifts in cloud, open source, and AI into clear product strategy and enterprise growth.