How Far Down Does It Go?

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 answer involves a threat model: is a physical attacker in scope, and for this product, at this price, in this market, is that reasonable? The threat model 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. It becomes 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 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.

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. The sentence also 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 minimization).

Annex I, Part I, (2)(g)

Data minimization, 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 favor: "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.

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 the vagueness is deliberate, 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.

Being vague was not an oversight. This pattern is a deliberate and defensible drafting philosophy, applied consistently. Which is what makes it worth thinking about instead of just complaining about: this is what happens when a genuinely sensible legal instinct meets a field made of abstraction layers.

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. The product 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.

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 harmonized 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 with no safe harbor attached. So what we are waiting for is a decision about which standard counts, and that is a much less depressing thing to be waiting for.

A product with no known exploitable vulnerabilities cannot exist. 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 artifact 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 at rest breaks down on a device that boots by itself. 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. Storing it there 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.

Monitoring must be minimized and left switchable at the same time. 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 minimize 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.

Cryptographic agility does not exist in fixed silicon. 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.

You must minimize an attack surface you are separately required to keep. 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.

Secure by default has to hold before any secret exists. 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.

Support has to continue for a platform that no longer exists. 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 license 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. Toolchain rot 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.

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 harmonized 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 the design. The specifics were always going to live somewhere else, written by people closer to the work and revisable without reopening the law.

The deferral 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. The gap 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.

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. Anything more specific dies on 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 organizations. The people in that figure are not dragging their feet, and the hours are the cost of trying in good faith to comply with something you 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. The drafting is careful throughout: the gap is between a legal abstraction that has to be singular and a technical reality that is irreducibly stacked.

Which means the standards do the real work, and I had been thinking of them as a formality. 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 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. No amount of reading the text more carefully changes that.