Secure by default, and the requirement that sits above the list

Practical guidance, not legal advice. Annex and article references are drawn from Regulation (EU) 2024/2847, and paragraph references from the Commission guidance C(2026) 5252, whose content was approved on 27 July 2026. Paragraph numbers can shift in the adopted text. Check everything below against the official texts before you rely on it.

Two requirements in Annex I Part I stall a first assessment more than the rest put together, and they do it for opposite reasons. Point (2)(b) looks trivial and turns out to hold three separate duties. Point (1) looks like a preamble and turns out to be the only requirement in Part I with no way out of it.

They belong in one read, because the second is what catches whatever the first, and the eleven points beside it, do not.

What point (2)(b) actually says

Annex I Part I(2)(b) requires products to be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state.

Three things are being asked. The configuration the product ships in is the secure one. There is a way to put the product back into its original state. And a narrow exception exists where a business user has agreed otherwise for a tailor-made product. Teams routinely answer the first and treat the other two as detail.

Secure by default, in three product shapes

The requirement is about the configuration a customer receives, not the configuration your best customer eventually reaches. What that means differs a lot depending on what you ship.

The default that lives in the quickstart

The most common way this requirement fails is not in the product. It is in the getting-started page, where the copy-paste command carries a flag that turns off exactly the control the default configuration enabled. Certificate verification disabled to get through a field trial. An environment variable that allows anonymous access so the docker-compose example works in one step.

The Regulation asks about the configuration the product is made available with, so a permissive quickstart is not literally a breach of point (2)(b). It is still the first thing an assessor finds, and it undermines the answer you gave. If the fast path has to be insecure, mark it as such in the documentation and make the secure path the one that is one command long.

The tailor-made carve-out, and how narrow it is

The exception exists for tailor-made products. The Article 3 definitions describe a tailor-made product with digital elements as one specially designed and developed for a specific business user, or built to that user's specific requirements, and not intended to be made available to other users. Check the definition before you lean on it, because the word covers less than teams assume.

Three conditions have to hold together.

• The product is genuinely tailor-made. A standard product with a configuration flag set differently for a large account is not a tailor-made product, however large the account.
• The other party is a business user. The carve-out has no consumer version.
• There is an actual agreement, and you can produce it. A sales conversation is not an agreement; a signed statement of work that records the varied defaults and why is.

What the agreement changes is the configuration, not the requirement. You still have to know what your secure default would have been, and you still have to explain why this deployment departs from it.

The same carve-out shape appears once more, in Annex I Part II(8), where security updates must be free of charge unless otherwise agreed with a business user for a tailor-made product. Different duty, identical structure. If you rely on it in one place, check whether you meant to rely on it in the other.

Reset to the original state

Original state means the state the product was in when it was placed on the market, not merely whatever a button labelled reset happens to do. Two questions decide whether your answer holds: what does reset actually touch, and can the user find it.

Note that this is not the same duty as erasing user data. That is point (2)(m), which is a separate requirement with its own limbs. In most products one button does both jobs, which is why teams tend to answer one and assume they answered both. A device that restores factory settings but leaves the paired account, the Wi-Fi credentials and the recorded footage in place satisfies (2)(b) and fails (2)(m).

• On a device: a documented procedure that returns configuration, credentials and pairing state to the shipped values, reachable without the app and without the cloud, because the reason people reset is usually that one of those is broken. Require physical presence, so the reset itself is not a remote denial of service.
• On embedded firmware: a recovery path that survives a bad configuration, typically a rescue image or a bootloader mode entered by a physical action. Document what the recovery image contains and how it is authenticated.
• On installed software: a supported way back to a known-good default, such as a documented reset command or a reinstall that does not silently adopt the old configuration directory. Say in the documentation which files and directories reset touches and which it leaves alone.

One design tension is worth naming because it has no obvious answer. If reset returns the unit to its original state literally, it can reinstate the firmware version that shipped in 2027, with every vulnerability you have fixed since. Most manufacturers resolve this by resetting configuration to shipped defaults while keeping the current firmware, and that is a defensible reading of a risk-based requirement. It is still a judgement. Write down which behaviour you chose and the reasoning, because this is precisely the kind of point where a recorded justification is worth more than a confident answer.

Point (1): the requirement above the list

Annex I Part I(1) requires products with digital elements to be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

Read it next to point (2) and the difference is structural. Point (2) opens by saying that its requirements apply on the basis of the risk assessment and where applicable, which is the hook Article 13(3) uses to let you record that a particular point does not apply to your product. Point (1) carries no such qualifier. There is no non-applicability determination available for it, which is why a tool that lets you mark it not applicable is wrong about the Regulation.

So what does answering it mean in practice? The Commission's guidance takes it up in section 7.2, at paragraphs 164 to 166. The reading there is that point (1) is a general requirement, and that where the applicable requirements of Part I(2) address the risks your risk assessment identified, point (1) is deemed fulfilled. That is the regulator explaining how it reads its own text. It is not the text, and guidance does not bind you the way the Regulation does.

The useful half of that reading is the residual case it implies. Where your risk assessment identifies a risk that none of points (2)(a) to (2)(m) reaches, point (1) is the requirement that obliges you to treat it anyway. Two examples that come up often: a build and signing pipeline whose compromise would let an attacker ship a legitimate-looking update, and physical tampering with a unit installed in a public place. Neither maps cleanly onto a lettered point. Both belong in a risk assessment, and point (1) is where the measure you took gets recorded.

In an assessment, then, point (1) is not a separate engineering task. It is a traceability question: for each risk you identified, which measure treats it, and is that measure written down somewhere an authority could follow.

What an assessor will expect

• The shipped default configuration as an artefact, not as prose. The actual default configuration file, the factory provisioning record, the installer defaults committed in the repository at the release tag.
• Evidence that a real unit or a clean install is in that state. A test that boots a factory image and asserts the defaults is worth more than a paragraph claiming them.
• The reset procedure, documented in the Annex II information that ships with the product, plus a test showing it does what the documentation says.
• Any tailor-made agreement that varies the defaults, naming the business user and the departure.
• A table tracing each risk in the Article 13(2) risk assessment to the measure that treats it. This is what Annex VII part 3 is asking for, and it is where point (1) is answered.

The trap

Almost every team asked whether their product is secure by default answers by talking about passwords. Default credentials are the famous failure, and they are one line in the configuration. The rest of the shipped configuration is where the unexamined decisions are: which services start, which interfaces listen, which protocol versions are accepted, whether telemetry is on, what the update setting is, and which of those a user has to actively change to make themselves less safe rather than more.

Print your product's default configuration and read it line by line. Most teams that do this find at least one setting nobody chose.

Vandorisk asks these as separate questions rather than one, records the tailor-made agreement where you rely on it, and carries the risk-to-measure trace through into the Annex VII file, so point (1) is answered by the same evidence that answers everything under it.