I spent part of a holiday reading the Cyber Resilience Act properly, which tells you something about the holiday. What I came back with is not a complaint about regulation. It is a question I cannot answer, and which I do not think the text can answer either: when a law says a product must protect its data, how far down into the product does that reach? To the file, the flash, the bus, the copper? Somewhere there is a line, and everything interesting about this legislation is in the fact that nobody has drawn it.
20 July 2026·16 min read
Start with the thing that prompted it, which is smaller than the regulation and stayed with me longer.
A colleague asked, half joking, whether we were now supposed to encrypt the circuit board. It was a joke about scope, and I laughed, and then I could not construct the argument for why the answer is obviously no.
Here is why it is not obvious. The regulation requires that a product protect the confidentiality of the data it stores. On a connected device that data sits in a flash chip. The flash chip is a separate package from the processor, connected by a bus, and that bus is a set of traces on a board that anyone holding the device can put a probe on. If the requirement is that the data be protected, and the data is legible on a wire inside the enclosure, then a filesystem-level answer has satisfied the sentence without satisfying the sentence's purpose.
Every engineer reading that knows the real answer involves a threat model: is a physical attacker in scope, and for this product, at this price, in this market, is that reasonable? That is the correct way to think about it and it is exactly what the regulation says, in the form of a requirement for "an appropriate level of cybersecurity based on the risks". Which returns the question to the manufacturer, unanswered, and makes it a matter of opinion at the exact moment it needs to be a matter of fact, because the answer determines whether there is a secure element in the bill of materials.
So the joke about the circuit board turns out to be the whole subject. Not because anybody thinks you should encrypt a board, but because the question "how far down" has no principled stopping point in the text, and engineering is entirely made of layers.
It is worth reading the actual language rather than a summary of it, because the summaries all sound more decisive than the text does. Everything quoted below is from Annex I of Regulation (EU) 2024/2847, and the subpoint references are there so you can check me.
Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.
Annex I, Part I, (1)
The governing sentence, and the one every other requirement is qualified by. It is also the sentence that hands the judgment back to the manufacturer, who will discover whether the judgment was right only in the event that something goes wrong.
[Products shall] be made available on the market without known exploitable vulnerabilities.
Annex I, Part I, (2)(a)
Seven words that no shipped product has ever satisfied, for reasons I will come back to.
[Products shall] protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means.
Annex I, Part I, (2)(e)
Note what is absent: no mention of end-to-end, no named algorithm, and crucially no layer. "Relevant" and "state-of-the-art" carry the entire obligation and neither is defined anywhere in the regulation.
[Products shall] process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation).
Annex I, Part I, (2)(g)
Data minimisation, and unarguable on its own. Hold it in mind for the next quotation.
[Products shall] provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user.
Annex I, Part I, (2)(l)
Three subpoints later: record the security-relevant activity, and let the user switch the recording off. Both of those are defensible. They are not obviously compatible.
[Products shall] be designed, developed and produced to limit attack surfaces, including external interfaces.
Annex I, Part I, (2)(j)
The clause the debug header lives under. "Limit" rather than "eliminate" is the only reason it is satisfiable at all, and also the reason nobody can tell you when you are finished.
[Manufacturers shall] identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.
Annex I, Part II, (1)
Worth reading in the manufacturer's favour: "at the very least the top-level dependencies" is a far smaller obligation than the full transitive graph everyone assumed, and one of the few places the drafting clearly knew what it was asking for.
Two words in there are doing more work than any two words should.
The first is relevant. Relevant data, encrypted at rest. Relevant to whom, assessed against what, and decided by which party? A device's designer, its operator and a regulator reasoning backwards from an incident will produce three different lists, and only the third one matters, and it is written last.
The second is state of the art. This one is more interesting than it looks, because it is not vague by accident, it is vague on purpose and for a good reason: a law that names a cipher is obsolete the moment the cipher is, and amending legislation takes years. So the drafters wrote a term that moves. The cost of that choice is that the requirement is no longer a property you can design against, it is a moving reference that will be evaluated at a date you do not know, by someone applying a standard that had not been written when you chose your parts.
Before I read the text I assumed the trouble was the ambiguity of "end-to-end encryption", a phrase that genuinely does mean different things to different people. The phrase does not appear. What is there is looser, and looser is worse. An ambiguous term at least gives you something to argue about. An undefined one gives you nothing to hold.
And this pattern is not an oversight. It is a deliberate and defensible drafting philosophy, applied consistently. Which is what makes it worth thinking about rather than just complaining about: this is what happens when a genuinely sensible legal instinct meets a field made of abstraction layers.
Because the layer problem is the real one, and I do not think it is solvable by better drafting.
A law has to talk about products, because a product is a thing that is placed on a market, sold to a person, and has a manufacturer who can be held responsible. That is the only unit legislation can address. It is the right abstraction for the law and it is a fiction from where I sit.
What we actually build is a stack. An application on a runtime on a kernel on a bootloader on a chip, with data crossing between them, each layer with its own idea of what a secret is and who is allowed to see it. Ask where "the data" is and there is no single answer: it is in a variable, in a page of memory, in a filesystem, in a flash block, on a bus, and it is a different problem at every one of those.
So a requirement addressed to "the product" lands on a thing that has no single interior. It has to be resolved into a layer before it becomes work, and the text does not say which one. Encrypting at the filesystem is a fortnight. At the block device is a month. At the memory interface is a component change and a board respin. All three are honest readings of the same sentence, and they differ by two orders of magnitude in cost.
And the choice cannot be deferred, which is the part that I think is genuinely not understood by people who have only shipped software. Software can be corrected late; that is its defining property. A secure element either is on the bill of materials or it is not, and that was settled eighteen months before anyone wrote the firmware. By the time there is a definitive answer about how far down the requirement goes, the boards for the products it applies to will have been fabricated.
The serial port is the sharpest form of the question, and it has a better answer than I expected, from a place the law is not yet looking.
Every embedded device has a debug console, and usually a JTAG or SWD header, because you cannot develop one otherwise. On a pre-production board those are indispensable. On a shipped unit the same pads are an unauthenticated root shell soldered to the outside of your product.
Is that an external interface, to be limited? Obviously yes. Does the obligation reach an engineering sample that never leaves the building? Here the framework is clear, and the clarity comes from somewhere unglamorous: everything hangs on "placing on the market", which is settled European product law with decades of practice behind it. A prototype not supplied for distribution or use has not been placed on the market. Pre-production is outside. That question does have a real answer, which is worth saying, because I have watched it consume weeks of argument.
The second question is what to do about the ports on units you do ship, and the answer already exists, written down, in ETSI EN 303 645. That standard defines a debug interface explicitly as including test points, UART, SWD and JTAG, and requires them disabled on production hardware. Precise, testable, implementable. You can hand it to an engineer on a Monday.
Which reframes my frustration, and improved it. The knowledge is not missing. Standards bodies have been doing this carefully for years and much of what the harmonised standards eventually say will resemble what these documents already say. What is missing is the pointer. Somebody has to formally name that standard as one of the ones that earns you a presumption of conformity, and until they do it is a good document rather than a safe harbour. So what we are waiting for is a decision about which standard counts, not the knowledge of what to build, and that is a much less depressing thing to be waiting for.
Some of the requirements, though, are not waiting on an index. Read literally, they ask for things computing does not permit, and every real team quietly substitutes a weaker reading and hopes it was the intended one.
Take any shipping connected device. It runs a kernel, a libc, a TLS library and several dozen other components, and at every instant there is a non-empty set of published exploitable vulnerabilities affecting some version of something in that stack. There has never been a moment in the history of the field when that set was empty. Worse, this is not a property of the product at all: a device compliant at nine in the morning is non-compliant by five, because somebody published an advisory, while the device has not changed by a single bit. A requirement whose truth value changes without the artefact changing cannot be a design requirement. Everyone reads it as "nothing known and unpatched, in the parts you control, at the moment you ship", which is sensible, achievable, and not what it says.
Encryption needs a key. If the device must come back up unattended after a power cut, with nobody present to supply a passphrase, then the key must be somewhere the device can reach on its own, which means on the device. Against an attacker holding the hardware you have stored the key beside the lock. This is not laziness, it is a bootstrapping problem with no software solution: the only real answer is a root of trust that releases the key solely to attested firmware, which is a component, chosen at schematic time. So the requirement is either trivial or it is a hardware decision, and nothing in the text distinguishes which is being asked for.
This one is a contradiction internal to a single page. Record relevant internal activity, including access to and modification of data. Process only data adequate, relevant and limited to what is necessary. Provide the user an opt-out from the recording. Each is defensible in isolation and I would defend all three. Together they instruct a manufacturer to maintain a security-relevant audit capability out of data it is obliged to minimise and that its users may switch off, and there is no configuration of a real system that satisfies all three strongly at once. What happens in practice is that one of them wins quietly, chosen by whoever implements it.
State of the art moves, and the regulation is explicit that it moves. The cipher engines in a microcontroller do not. An industrial device certified in 2027 with a twenty year service life will spend most of that life carrying a hardware implementation that stopped being state of the art a decade earlier, and no update changes it, because it is etched. Post-quantum migration turns this from a thought experiment into a purchasing decision. The rational response is to oversize the crypto hardware now against a guess about 2040, which is a real cost paid today for a definition that will be applied later.
Permanently disable the debug interface and you have limited the attack surface, exactly as asked. You have also made it impossible to perform failure analysis on a returned unit, and for anything safety-relevant, root-cause analysis of field failures is an obligation under a different regime entirely. Two regulators, each correct alone, issuing opposite instructions about the same six pads. The industry answer is an authenticated debug unlock, which is good engineering and a surprising amount of it for something no customer will ever see.
A device out of the box shares no secret with its owner. To be commissioned it must accept something from someone: a pairing request, a temporary access point, a Bluetooth session. Until that first exchange there is by construction no way to tell the legitimate owner from anyone else in radio range. You can narrow the window, demand physical presence, print a unique credential on the housing. You cannot make the window not exist. Secure by default and works out of the box overlap in a region somebody has to occupy.
The support obligation runs for the expected lifetime of the product. Consider a device shipped in 2028 with a ten year life. By 2034 the silicon vendor has discontinued the part and taken the SDK offline, the RTOS company has been acquired and the licence server it checks in with is gone, and the toolchain will not build on any operating system you are permitted to run. You owe a patch for a system nobody can compile. This is among the most common real failures in long-lived embedded products, and the text has nothing to say about it, because it is a supply chain problem wearing a software costume.
There is an answer to most of this, and it is worth understanding properly, because it is where my sympathy for the drafters comes from.
The regulation was never meant to be read the way I have been reading it. European product law works by deferral: the legislation states outcomes, and a separate body of harmonised standards states how to achieve them. Build to a cited standard and you get a presumption of conformity. The vagueness I have spent this piece picking at is not a defect in that design, it is the design. The specifics were always going to live somewhere else, written by people closer to the work and revisable without reopening the law.
That is genuinely elegant, and it is why "state of the art" can appear in a legal text without being absurd. The standard is where state of the art gets pinned down, and the standard can be updated on a timescale that matches the field.
The difficulty is that the mechanism only works when the standards exist, and right now they do not. The request went to the standards bodies in early 2025, the horizontal drafts are still in development, none has been cited in the Official Journal, and the Commission moved the drafting deadlines back another two months this month. So for the moment we have the half of the system that states outcomes and not the half that says how, and the gap is being held by manufacturers making decisions that cannot be revisited.
I do not think that is a scandal. Standards work is slow because it is done properly, and rushing it would produce something worse. It is more like a design that assumed two components would arrive together, and one of them is late, and the load is being carried in the meantime by whoever is nearest.
And the case against my own position, which deserves to be made properly rather than waved at.
The obvious retort is: fine, then write it precisely. Say AES-256, say secure element, say disable UART. And the reason the drafters did not is sound. A regulation naming a cipher is obsolete when the cipher is. Outcome-based drafting is what lets one instrument cover a doorbell, a router and a programmable logic controller without becoming a catalogue that is wrong within five years. That is not laziness, it is the only shape that survives contact with a field moving faster than any legislature.
The second retort is more uncomfortable and I think it lands. Connected products have been sold into Europe for twenty years with default passwords, no update path and no way to report a flaw, and no amount of good engineering culture fixed it, because the market did not price it. Something like this was necessary. Its central instinct, that if you place a connected thing on the market you own its security for as long as you support it, is simply correct, and most of my discomfort is the discomfort of being asked to be accountable for something that used to be free.
Where I hold my position is narrower. The philosophy is right and the drafting is competent, but the model of engineering underneath it is a software model. Nearly every requirement in Annex I can be satisfied late by a competent software team: patch it, ship the update, publish the list, run the disclosure process. Almost none of them can be satisfied late by a hardware team, because the decisions they force were made when the board was laid out. That asymmetry is invisible in the text, and it is the difference between an obligation that is demanding and one that is unbudgetable.
The evidence that this is landing awkwardly is not anecdotal. The OpenSSF's readiness work in June found awareness across that ecosystem still stagnant, and put the compliance burden at over eleven thousand engineering hours per cycle for large organisations. That is not a number produced by resistance to the goal. It is produced by people trying in good faith to comply with something they cannot yet read precisely.
So: how far down does it go? I still do not know, and I have come to think the question is more interesting than the answer would be.
A law can only address products, because a product is the only unit that has a manufacturer, a market and a moment of sale. Engineering has no products. It has layers, and every one of them can be made secure or left open independently of the others, and a sentence addressed to the whole must be resolved into one of them before anybody can act on it. Nothing in the drafting is careless. The gap is between a legal abstraction that has to be singular and a technical reality that is irreducibly stacked.
Which means the standards are not a formality, and I had been thinking of them as one. They are the translation layer, the only place the question actually gets answered, and the fact that we are all arguing about the regulation while waiting for them is a sign we have been reading the wrong document. The interesting work is happening in the standards bodies, quietly, while everyone shouts about the law.
And in the meantime somebody has to decide whether there is a secure element on the board, and that person is not going to get an answer in time, and they will decide anyway. That is the actual condition, and no amount of reading the text more carefully changes it.