Does the EU CRA let a CE-marked industrial gateway keep its default engineer account?

## Why the account is a problem under the CRA The CRA's essential requirements for products with digital elements are not a vague call to be secure. Several of them land directly on a shared default account: - products must be **made available with a secure-by-default configuration**, including the possibility to reset to that state - products must **protect from unauthorised access by appropriate control mechanisms**, including authentication and identity or access management, and report on possible unauthorised access - products must be designed to **minimise attack surface** - products must be **placed on the market without known exploitable vulnerabilities** - products must **record and monitor security-relevant internal activity**, including access to the product A support account whose credential is identical across the fleet, printed in a service manual and never rotated, fails secure-by-default, fails access control, expands attack surface for no per-customer benefit, and is a known exploitable weakness the moment the manual leaks. Note the last requirement carefully: the duty is no **known exploitable** vulnerabilities, not no vulnerabilities at all - nobody can promise the latter, and a candidate who claims the CRA demands perfect software has misread it. ## The position and the asset This is not the usual anonymous-attacker-steals-customer-data story, and that matters for how you argue it internally. The realistic attacker here is someone with legitimate physical or network access: a contractor on a commissioning visit, a technician who changed employer, an operator inside the plant network. The asset is not a database; it is the safe operation of a physical process, and availability of the control path. That reframing usually wins the argument with a product manager faster than the regulation does, because the failure mode is a stopped line or an unsafe state rather than a fine. ## What replaces it Removing the account outright and telling the field to cope is how a compliance programme gets sabotaged by the people who have to live with it. Design the replacement around the same operational need - a technician standing at a gateway that is misconfigured, possibly with no network - and the requirements are met without breaking anyone: 1. **Per-unit initial credentials.** A unique factory credential per device, printed on the label or delivered with the asset record, with a forced change on first use. This is the minimum that satisfies secure-by-default and it is cheap. 2. **Per-technician identity for routine access.** Where the gateway can reach an identity source, individual accounts with real roles, so access is attributable and revoked when the technician leaves. 3. **A break-glass path that is deliberate.** Local console or physical-presence access - a button press, a jumper, a signed short-lived service token that the device validates offline - so a technician can recover a gateway with no connectivity, without that path being remotely reachable by anyone else. 4. **Logging that survives.** Record who used the recovery path and when, exportable to the operator, so the access is auditable rather than invisible. 5. **A migration for installed base.** New units ship correct; deployed units get the change through the update mechanism, with a window and clear communication to asset owners before the old credential stops working. ## The conformity question people get wrong Engineers assume that changing authentication on a CE-marked product forces a fresh conformity assessment, and use that as a reason to delay. A security update that fixes vulnerabilities without modifying the intended purpose is not a substantial modification, so it does not trigger reassessment. What would trigger it is a change to intended purpose or one that affects compliance in other respects. Get this right in the interview: the regulation is constructed so that patching is never the expensive path. ## The organisational fallout The hard part is field operations. Expect: technicians with a decade of muscle memory, a service documentation set that must be reissued, integrators and distributors who baked the default into their own runbooks, sites where the gateway genuinely has no route to any identity system, and asset owners under change-control regimes who cannot accept a firmware update without a scheduled outage. Handle it as a rollout, not an announcement: pilot with one integrator, publish the replacement procedure before removing the old path, keep a supported offline route so nobody has an excuse to demand the default back, and give the field a number to call during the transition. ## What good answers include Name the specific essential requirements rather than saying it is insecure; distinguish removing the capability from re-founding it; mention the installed base explicitly; and say out loud that the security update is not a substantial modification. Weak answers stop at *default passwords are bad*.