Who gets in, and what they can read

Practical guidance, not legal advice. Annex and article references are drawn from Regulation (EU) 2024/2847. Check them against the official text before you rely on them.

These two points sit next to each other in Annex I and are usually answered by the same engineer in the same afternoon, which is roughly right. Point (2)(d) is about who reaches the product and what they are allowed to do once they have. Point (2)(e) is about what any of them can read.

Both contain something that gets skipped. In (2)(d) it is a whole second duty hidden at the end of the sentence. In (2)(e) it is a phrase that sounds like it has a definition and currently does not.

The half of (2)(d) that gets skipped

Point (2)(d) requires products to ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and to report on possible unauthorised access.

That last clause is a separate obligation. Preventing unauthorised access is one thing; the product reporting on possible unauthorised access is another, and it is the one that goes unanswered. It also is not the same duty as the logging requirement in point (2)(l). Logging is about the record existing. Reporting is about somebody being told.

• A consumer device can surface it in the companion app: a new sign-in from an unrecognised location, a run of failed attempts, a configuration change made remotely.
• An industrial unit usually has no user to tell, so the report goes where the operator already looks: a syslog target, an SNMP trap, an alarm register the SCADA system polls, an event on the fieldbus.
• Installed software should raise it through whatever the deployment already watches, and should also make it queryable, so the customer's own tooling can pull an authentication event feed rather than parsing a text log.

The test is simple to state and often fails. Attempt to log into your own product incorrectly ten times. Does anyone, anywhere, find out?

Authentication, by product shape

Connected devices

Either the unit ships with a per-device secret or the user is forced to create one during setup. There is no third option that survives review.

The failure mode worth naming is the unique-looking default that is computable. A password derived from the serial number, the MAC address, or a date of manufacture is a shared default with an extra step, because those values are printed on the box, broadcast on the network, or guessable within a small range. If the algorithm can be recovered from one unit, it applies to the fleet.

Rate limiting matters more than complexity rules here. Prefer exponential backoff over a hard lockout: a lockout that any unauthenticated stranger can trigger is an availability problem you have just built for yourself, which is point (2)(h)'s business.

Embedded firmware and machine-to-machine identity

Most authentication in an embedded product is not a human logging in. It is a device proving itself to a backend, or two devices proving themselves to each other. The right answer is per-device credentials provisioned at manufacture, ideally a private key generated inside a secure element that never leaves it, with mutual TLS or an equivalent.

The recurring failure is one shared pre-shared key, or one client certificate, across an entire fleet, because provisioning per-unit secrets on the line was a manufacturing problem nobody wanted to solve. Extracting one unit's key then gets you every unit. If that is your situation, the honest move is to record it in the risk assessment as a known residual risk with a migration plan, not to describe the fleet key as authentication and hope.

Software the customer runs

Do not build your own identity system. Support the identity the buyer already has: OIDC or SAML against their provider, and the platform's own account model where there is one. Separate an administrator role from a user role from a read-only role, and make the separation real on the server rather than in the interface.

Which is the other half of this point. Authentication answers who you are; access control answers what you may do, and it has to be checked where the decision is enforced. The classic firmware version of this bug is a web interface that hides the administration page from non-admins while the underlying endpoint answers anyone who asks for it directly. The classic software version is an object identifier in a URL that nobody checks belongs to the caller.

Confidentiality, and what state of the art means today

Point (2)(e) requires products to 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.

State of the art is doing a lot of work in that sentence, and it is worth being precise about its status. Under other EU regimes the phrase is anchored by standards that have been cited in the Official Journal. For the CRA, no harmonised standard has been cited in the Official Journal as of August 2026, so nothing gives you a presumption of conformity by applying it. Verify the current position before you rely on this; it is the kind of fact that changes.

What that leaves you with is an obligation to make a defensible choice and record why it was defensible at the time. The practical method is to name a published, maintained reference and cite the version and date you assessed against.

• SOG-IS Agreed Cryptographic Mechanisms, widely used across European evaluation work.
• BSI TR-02102, updated annually, which is unusually direct about what is acceptable and for how long.
• NIST SP 800-131A on algorithm transitions, and the associated key-length guidance.
• ANSSI's cryptographic mechanism guidance, where a French deployment is in scope.

None of these is required by the CRA and none confers presumption of conformity. They are how you show that your choice tracked informed opinion rather than habit. Record which one you used, which version, and the date, because state of the art is a moving target and your file has to show where the target was when you aimed.

The floors that are not controversial

Separately from the reference you cite, some things are settled enough that failing them will not be defended.

• TLS 1.2 with modern cipher suites at minimum, TLS 1.3 preferred, with certificate validation actually enabled in the shipping build.
• AES-GCM or ChaCha20-Poly1305 for data at rest. Authenticated encryption, so tampering is detected rather than decrypted into nonsense.
• Argon2id, scrypt or bcrypt for stored passwords, with parameters you chose deliberately. A bare SHA-256 of a password is not password storage.
• No key material committed to a repository, baked into a firmware image, or shared across a fleet.

The embedded failure that keeps recurring is certificate verification switched off during a field trial, in a build flag nobody removed, in a product that shipped. It is worth a specific test rather than a code review, because it is invisible in the source and obvious on the wire.

Relevant data, and where relevance comes from

The text says relevant data, which is not the same as all data. Relevance comes from the assets you listed in the Article 13(2) risk assessment. That is the link an assessor will look for: the data you identified as worth protecting, and the mechanism protecting each category of it.

Encrypting everything without knowing what matters is not an answer to this point, and it hides the case where the one thing that mattered was written to a log file in the clear.

At rest, on a device that boots unattended

This deserves an honest paragraph, because it is where product marketing and engineering reality separate. If the decryption key is stored on the same flash chip as the encrypted data, so the unit can boot without a human, then encryption at rest raises the cost of an attack from trivial to moderate. It does not stop someone with the device in their hands and a few hours.

The real control is a key that lives somewhere the flash reader cannot follow: a secure element, a TPM, one-time-programmable fuses, or a key wrapped by measurements from the secure boot chain so it only unwraps on an untampered unit. If your bill of materials does not include that hardware, say so in the risk assessment, describe what your at-rest encryption does and does not defeat, and let the residual risk be visible. A file that overstates the protection is worse than one that records the limit.

What an assessor will expect

• The authentication design, including where credentials and keys originate, where they are stored, and how they differ per unit or per tenant.
• An inventory of cryptography in use: protocol, algorithm, key length, and where each is applied, plus the reference you assessed it against and its date.
• Negative test results. No default credential on a factory image. No unauthenticated request reaching a privileged function. No plaintext protocol enabled by default.
• The mechanism that reports possible unauthorised access, plus where a user or operator sees it.
• Any residual risk you accepted, such as a fleet key or an unprotected at-rest key, written into the risk assessment rather than left out of it.

The test evidence belongs in Annex VII part 6, and where you met these requirements without applying a harmonised standard, which today is everyone, the reasoning belongs in Annex VII part 5.

The library's article on regular security testing covers how to produce that evidence at a cadence you can defend, and the piece on writing the evidence once explains why the same cryptography inventory answers the equivalent questions under RED and the Machinery Regulation.