Security regulation for connected products
Security is becoming a continuous obligation with a duration attached, rather than a gate passed at launch. What the three regimes cover, which requirements change how you build, and why the update mechanism decides everything else.
In short
- Security is becoming a continuous obligation, not a gate passed at launch. That is the structural change.
- A stated support period is the hard commitment. It means keeping a build environment and people, for years.
- If you cannot update it, you cannot fix it. Every other requirement depends on that mechanism working.
- Three regimes, different scopes. Consumer baseline, EU product duties, industrial systems framework — not alternatives.
- Most of this is cheap designed in and expensive retrofitted, which is the usual pattern and still surprises people.
What has actually changed
For most of the history of connected products, security was a quality matter: you did it well or badly, customers might ask, and nothing external obliged you. That is ending, and the structural change is not that security requirements exist — good practice has been documented for years — but that they are becoming continuous obligations with durations attached.
A conformity mark is earned once. A product is assessed, a declaration signed, and provided nothing changes the matter is closed. Security regulation does not work that way. It asks what you will do when a vulnerability is discovered in three years’ time, how you will find out, how you will deliver the fix, how quickly you will tell the authorities if it is being exploited, and when you will stop. Those are commitments about the future rather than statements about the product.
That has consequences for engineering and for business planning, and the engineering consequences arrive first: a product that cannot be updated in the field cannot meet a continuing obligation, whatever its design quality at launch.
This article describes the general shape of these regimes to help plan engineering work. It is not legal advice, it is not a statement of what applies to any particular product, and the detail changes — obligations phase in, guidance is published, and classifications are clarified. Confirm the current position and your product’s classification with a qualified adviser. We do engineering and documentation; we do not certify products or advise on legal obligations.
Three regimes, three different scopes
These are frequently discussed as though they were competing options. They are not: they address different things and more than one can apply at once.
| Applies to | Concerned with | Nature | |
|---|---|---|---|
| Consumer IoT baseline EN 303 645 and similar |
Consumer connected products | A floor of basic expectations | A standard; referenced by legislation in several jurisdictions |
| EU product security Cyber Resilience Act |
Products with digital elements on the EU market | Manufacturer duties across the whole product life | Regulation, with conformity assessment and phased obligations |
| Industrial automation IEC 62443 series |
Industrial automation and control systems | Systems, and the roles around them | A standards framework; certification available, sometimes demanded |
The distinction that matters most in practice is product versus system. A device manufacturer’s obligations attach to the thing they sell. An industrial system’s security depends on how devices are arranged, segmented and operated, and no product can deliver that on its own. A vendor claiming their device makes a plant compliant with an industrial framework has misunderstood the framework, and a plant assuming that buying certified components produces a secure system has made the same error in the other direction.
The consumer baseline, which reaches further than consumers
The baseline expectations for consumer connected products are modest and worth knowing even for industrial suppliers, because procurement departments have adopted them as a general checklist. The ones that recur:
- No universal default passwords. Either unique per device, or forced to be set at first use. This single item is responsible for a large share of historical compromises.
- A means to report vulnerabilities. A published contact and a commitment to act on what arrives. Costs nothing and is frequently absent.
- Software kept updated. An update mechanism, and a stated support period.
- Credentials stored securely, not hard-coded in firmware where anyone reading the binary will find them.
- Communications secured, with certificates actually validated rather than accepted.
- Minimised attack surface: services and ports not needed in the field, closed.
- Personal data handled properly, where any is involved.
None of this is demanding, and all of it is markedly cheaper designed in. The engineering practice behind each is covered in device security and OTA updates; the point here is that these items increasingly appear in contracts regardless of sector.
The obligations that change how you build
Several requirements common to these regimes have real engineering consequences, and three of them are decided at architecture rather than adjusted later.
An update mechanism that can be relied on
Everything else depends on this. An obligation to fix vulnerabilities during a support period is unmeetable if fixes cannot reach the field, and a product without a working update path is one whose only remedy is a recall.
The requirements are unglamorous and well established: updates must be authenticated so a device will not accept an unsigned image, delivery must survive interruption without leaving an unbootable device, there must be a way to recover a device that receives a bad update, and the mechanism itself must be secure — an update channel is an excellent way to compromise an entire fleet if it can be subverted.
The constraint people meet late is resource. Retaining two firmware images for a safe rollback roughly doubles the flash a device needs for firmware, and a microcontroller chosen to be adequate without that provision cannot be given it later without new hardware. This is the clearest case in the whole subject of a decision that is free at the start and impossible afterwards.
Knowing what your firmware contains
A software bill of materials lists the components your product is built from, including the third-party libraries nobody remembers adding. Its purpose is entirely practical.
When a serious vulnerability is announced in a widely used library, every manufacturer faces the same question: are we affected, and in which products? An organisation with bills of materials answers in minutes by searching. One without spends days reading source and asking former contractors, and typically cannot answer confidently at all. Anyone who lived through a widely publicised library vulnerability recognises the difference.
Generating one is largely automatable from the build, which is the right place for it, because a manually maintained list drifts from what is actually built. The harder part is keeping it linked to specific released versions, so a question about a device in the field can be answered about the firmware that device is actually running. That in turn requires knowing which version each device has, which is a fleet management question rather than a build one.
A route by which someone can tell you
Vulnerabilities are frequently found by people outside the organisation: researchers, customers, or someone who noticed something. Whether that becomes a manageable disclosure or a public surprise depends largely on whether there was an obvious way to make contact and whether anything happened when they did.
What is needed is modest: a published contact route, an acknowledgement that it is monitored, an internal process for assessing what arrives, and a stated approach to disclosure timing. The commonest failure is not the absence of a policy but the absence of anyone reading the mailbox, which converts a responsible disclosure into a public one by default.
The risk assessment, done so it is worth something
A documented risk assessment is required by these regimes, and it is the requirement most often satisfied with a document nobody reads. That is a missed opportunity, because a threat model done properly changes design decisions and takes a morning.
The version that earns its place answers four questions about the specific product:
- What is worth attacking here? Not everything is. A sensor reporting tank levels holds little of value, but it may sit on a network that does, and it may be usable to falsify a record somebody relies on. Being specific about what an attacker would actually want is what keeps the rest of the exercise grounded.
- Who could reach it, and from where? Physical access, the local network, the internet, the update channel, the manufacturing process, a service engineer’s laptop. Each is a different route with different plausible attackers.
- What happens if they succeed? Distinguish a compromised device from a compromised fleet. A flaw requiring physical access to each unit is a different proposition from one exploitable remotely across every device at once, and the second justifies far more effort.
- What would we do about it? If the answer is nothing, because there is no update path, that is the finding — and it is more important than the rest of the document.
Two habits make this useful rather than decorative. Do it with the people who will build the thing, not separately, so the conclusions land where decisions are made. And record what you decided not to defend against and why — a documented, reasoned acceptance of a risk is a legitimate engineering position and a defensible one. An assessment that claims everything is addressed is not credible to anyone who reads it carefully.
Secure boot, and whether you need it
Secure boot means the device verifies firmware authenticity before running it, anchored in something that cannot be changed — typically keys in one-time-programmable memory. It is the foundation the update requirements ultimately rest on: without it, a signed update is only as trustworthy as the code checking the signature, which an attacker with write access can replace.
It is also not free, and the honest position is that it is not always justified.
| Consideration | Detail |
|---|---|
| Silicon choice | Must support it. Cannot be added to a part that does not. |
| Manufacturing | Key provisioning becomes a production step, with its own security |
| Development friction | Signing in the development loop; unsigned test builds need a deliberate arrangement |
| Recovery | A device that will not accept unsigned code is harder to rescue when something goes wrong |
| Key compromise | If the signing key leaks, the protection is gone across the fleet, permanently on devices already shipped |
| Worth it when | Devices are physically accessible, a compromise would spread, or a customer or regulation requires it |
| Questionable when | Devices are in locked cabinets, the fleet is small, and nothing of consequence is reachable |
The decision must be made at silicon selection, which puts it early in the design. Our general position: if the product will be numerous, physically reachable, or connected to anything that matters, choose a part that supports it even if the feature is not enabled in the first release. Keeping the option costs a component choice; not having it costs a hardware revision.
Keys, over a decade
Key management is the part of this subject that receives the least attention relative to how much trouble it causes, because the difficulties appear years after the decisions.
- Where does the signing key live? On a build server is convenient and means anyone compromising that server can sign firmware. A hardware security module is the durable answer.
- Who can use it, and is that recorded? Signing should be an auditable action, not an ambient capability.
- What if it is compromised? If devices trust exactly one key with no mechanism to move to another, a compromise is unrecoverable for everything already shipped. Provision for rotation, even if never used.
- What about per-device identity? Devices that authenticate individually need unique credentials, which means generating and installing them in manufacturing without the contract manufacturer being able to extract them.
- Does it survive the people? Key custody arrangements that depend on one person’s knowledge fail when that person leaves. This is a documented process or it is a future incident.
The scenario worth considering concretely: it is four years from now, a vulnerability requires a firmware update, and the engineer who set up signing has left. Does the current team know where the key is, how to use it, and whether the build still reproduces? If not, the support commitment is not real regardless of what was stated.
What you inherit from other people
Most firmware is mostly other people’s code, and most products contain components somebody else designed. Both carry obligations.
Third-party code. Every dependency is a component you are responsible for despite not having written it. Practical consequences: know what you depend on, including transitive dependencies; monitor for announced vulnerabilities rather than waiting for a customer to notice; prefer dependencies with a maintenance record and a support horizon compatible with your product’s; and understand licence obligations, which are a separate matter from security but surface in the same review.
Modules and subassemblies. A radio module, a cellular modem or a system-on-module runs its own firmware with its own vulnerabilities and its own update path. Questions worth asking the supplier before selection: how long will you provide security updates, how will we learn about vulnerabilities, and can we update the module in the field through our own mechanism. A module with no update path inside a product you must keep patched is a problem you have bought.
Contract manufacturers. The manufacturing process is part of the attack surface. Firmware images and keys handled at the factory, test interfaces left enabled, and the possibility of unauthorised production all matter. What helps: provisioning designed so the manufacturer never holds the material that would let them build extra units, disabling debug and test interfaces as a production step that is verified rather than assumed, and treating the factory as a party to secure against rather than simply trust.
Products already in the field
Most of this article assumes a product being designed. The more common situation is an existing fleet, and pretending otherwise would be unhelpful.
The realistic sequence:
- Establish what exists. Which products, how many, where, which firmware versions. Many organisations cannot answer this, and the inability is itself the first finding.
- Determine what can be updated. Remotely, on site with a visit, or not at all. This sorts the fleet into categories requiring different responses.
- Assess the exposure. Devices unable to receive updates that are internet-reachable are the urgent category. Devices on isolated networks are a different risk, and treating both identically wastes effort.
- Decide what to do about the unfixable. Options are usually compensating controls — network segmentation, placing the device behind something that can be updated — a hardware replacement programme, or an accepted and documented risk. All three are legitimate; an undocumented assumption that it will be fine is not.
- Tell customers what they need to know. Uncomfortable, and better than the alternative discovery route.
Compensating controls deserve emphasis because they are frequently the only proportionate answer. A device that cannot be patched, placed behind a gateway that can be, on a segment that reaches nothing of consequence, is in a defensible position. That is an architecture decision rather than a product one, which is why the boundary design matters as much as the device.
What it costs
The distribution differs from most compliance work in one important way: a substantial part is recurring for the life of the product.
| Item | Nature | Notes |
|---|---|---|
| Secure design and threat modelling | One-off, modest | Cheapest at architecture; a morning well spent |
| Update mechanism | One-off, significant | Plus the flash it needs. Unavoidable. |
| Secure boot and key provisioning | One-off, plus production step | Silicon choice decides whether it is available at all |
| Bill of materials generation | One-off to automate, then free | Only useful if generated from the build |
| Dependency monitoring | Continuing | Largely automatable; someone must still read it |
| Producing security updates | Continuing, unpredictable | Driven by what is announced, not by your plans |
| Maintaining build and signing capability | Continuing | The quiet cost that makes the rest possible |
| Incident readiness | Continuing | Availability of people, rehearsed process |
| Conformity documentation | One-off, then maintained | Must describe what the product actually does |
The four continuing items are what a support commitment actually means in cash terms, and they are the ones omitted from business cases. A useful discipline is to estimate them per year per product line and multiply by the stated support period, then check whether anyone is prepared to fund that. If not, the support period is wrong, and it is better to know before it is published.
Reporting, and the part with a clock on it
The obligation that most changes operational reality is reporting. Where a vulnerability in your product is being actively exploited, or a severe incident affects your products, notification deadlines are short — measured in hours and days rather than weeks — and run from when you become aware.
That has practical implications beyond the engineering.
- Somebody must be able to make the decision at whatever hour the information arrives. A process requiring a committee cannot meet a deadline of hours.
- The assessment has to be possible quickly, which depends on knowing what is deployed, in what versions, with what components — the bill of materials and fleet knowledge again.
- Legal and communications need to be prepared rather than assembled during the event.
- Rehearse it. An organisation that has never walked through the sequence will not discover the gaps under time pressure at a convenient moment.
The distinction between a vulnerability and an actively exploited one matters here. Ordinary vulnerability handling runs on engineering timescales; active exploitation starts a clock. Knowing which situation you are in is itself part of the assessment, and it is worth deciding in advance who makes that call.
Support periods, and the commitment nobody enjoys making
Stating how long a product will receive security updates is the requirement with the largest business consequence, and it is where engineering and commercial reality meet uncomfortably.
Supporting a product for a decade means, for that decade: retaining a build environment that still works, retaining signing keys and the ability to use them safely, retaining people who understand the code or documentation good enough for new people, keeping test hardware, and keeping dependencies patchable — which becomes difficult as upstream projects themselves reach end of life.
| Requirement | Why it is difficult | What helps |
|---|---|---|
| A working build environment | Toolchains, operating systems and licences age out | Containerised, version-pinned, reproducible builds |
| Signing capability | Keys must remain usable and protected for years | Hardware security modules; documented key handling and rotation |
| People who understand it | Staff move on well within the period | Documentation written for someone who was not there |
| Test hardware | Early revisions become unobtainable | Retain units of each revision deliberately |
| Patchable dependencies | Upstream projects end support inside your window | Choose dependencies with long support; plan migrations |
| Commercial willingness | The revenue was recognised years ago | Price it in at launch, not later |
Two honest observations. A support period appropriate to the product is the expectation, and for industrial equipment with a fifteen-year service life a two-year period invites the obvious question. And the last row is the real constraint: the engineering is tractable, but the organisation has to remain willing to spend on a product it stopped selling. Deciding that at launch, and pricing it in, is the only arrangement that survives.
Ending support is also a positive obligation rather than simply stopping. Users should be told in advance and told what ends, because the device keeps working and keeps being attacked. Reproducible builds and long-term maintainability are covered in embedded firmware practice.
IEC 62443 in practice
The industrial framework is large, and the parts that matter depend on which role you occupy. A device vendor, a system integrator and a plant operator each have different obligations within it.
Two concepts are worth understanding even without pursuing certification, because they shape how industrial customers will talk to you.
Zones and conduits. The system is divided into zones of similar security requirements, with defined conduits between them. It is a structured way of expressing what the OT/IT integration article calls the controlled boundary, and it is how industrial customers will describe where your device is permitted to sit and what it may talk to.
Security levels. The framework defines levels reflecting the capability of the attacker being defended against, from casual or accidental exposure up to a well-resourced and determined adversary. A customer specifying a level is stating what your product must withstand, and the levels differ substantially in what they require.
For a supplier who has not been asked for certification, the useful approach is generally to understand the framework, design to the capability level customers in your sector expect, and document what you have done. Pursuing formal certification before a tender requires it is a substantial investment that may be better made later — though if your sector routinely demands it, that judgement reverses.
What usually goes wrong
- No update path. Every other obligation fails with it, and it cannot be added to shipped hardware.
- Insufficient flash for a safe update. Decided at component selection, unfixable afterwards.
- No record of what is in the field. Which devices, running which version, built from what. Without it, no vulnerability question can be answered quickly.
- A reporting mailbox nobody reads. Converts responsible disclosure into public disclosure.
- A support period chosen for comfort. Stated to satisfy a form, without the organisation committing to fund it.
- Treating it as a certification exercise. These are continuing obligations, and a one-off assessment does not discharge them.
- Assuming business-to-business exempts you. Procurement questionnaires have adopted the consumer baseline regardless of sector.
- Hard-coded credentials. Still common, still trivially recoverable from firmware.
Who owns this inside the company
A recurring reason these programmes stall is that the obligations cut across departments and land on nobody. Engineering builds the update mechanism but does not decide the support period. Sales answers the questionnaires without knowing what is true. Legal owns the regulatory question but cannot assess whether a device can be patched. Finance funds it and was not in the conversation.
The arrangement that works is unremarkable: one named person accountable for product security, not necessarily doing the engineering, but holding the answer to what is in the field, what can be updated, what has been promised and what happens when something is reported. They need enough authority to say a support period is unaffordable, or that a product should not ship without an update path.
Two decisions in particular need an owner because they are cross-functional by nature. The support period is an engineering capability, a commercial commitment and a customer-facing statement at once, and it must be decided with all three represented rather than written on a datasheet by whoever was filling in the form. The response to a report needs somebody able to act at short notice, which means an out-of-hours route and a deputy, not a role description.
For a smaller company this need not be a full-time position, and frequently should not be. What it must be is explicit. The failure mode is not an under-resourced owner; it is a subject everyone assumes somebody else is handling, which is how a researcher’s email sits unread in a sales inbox for eighteen months.
Where to start
For an organisation that has not addressed this, the order matters more than the pace.
- Establish what you have in the field. Which products, roughly how many, which firmware versions, and whether each can be updated remotely. This frequently produces uncomfortable answers and everything else depends on it.
- Fix the reporting route. A published contact, monitored. Cheap, immediate, and it closes the worst exposure.
- Generate bills of materials from the build for products in development, then retrospectively for those still supported.
- Assess the update mechanism honestly. Not whether it exists but whether it has been used at scale, and what happens when it is interrupted.
- Decide support periods deliberately, with whoever controls the budget in the room.
- Write down the vulnerability handling process, then walk through a scenario before you need it.
- Then address classification and conformity with qualified advice, once the underlying capability exists.
Taking the last step first is the common error. Conformity documentation describing capabilities you do not have is worse than none, because it is a written claim.
A worked situation
A manufacturer of industrial sensors, roughly four thousand units in the field across three product generations, sold through distributors into several countries. Customers have begun sending security questionnaires. Nobody in the company owns this subject.
What an honest first assessment tends to find:
- The oldest generation, around a thousand units, cannot be updated at all. Firmware is programmed at manufacture.
- The middle generation can be updated, but only over a local connection requiring a site visit. It has been done twice, both times awkwardly.
- The current generation supports remote update. The mechanism has been used once, on fifty units, and nobody has tested what happens if it is interrupted at scale.
- Firmware contains a network stack, a TLS library and an operating system, none of which anyone has checked for announced vulnerabilities. Version numbers are in a comment in a header file.
- There is no published security contact. A researcher emailed sales eighteen months ago and received no reply.
- All devices of a generation share one credential, hard-coded.
None of this is unusual, and the sequence that addresses it is not primarily technical.
Immediately: publish a security contact and route it somewhere monitored. Identify which library versions are actually in each generation and check them against published vulnerabilities — this typically takes days and answers the question customers are asking.
Within a quarter: automate bill-of-materials generation in the build. Test the current generation’s update mechanism properly, including interruption and recovery, on a meaningful number of units. Write down the vulnerability handling process and walk somebody through it.
For the fielded generations: the oldest is a compensating-controls conversation with customers — where are these devices, what can they reach, and does anything need segmenting. Documented, and communicated rather than hoped about. The middle generation needs a decision about whether a visit-based update campaign is warranted by what is found.
For the next product: secure boot, unique per-device credentials, sufficient flash for safe updates, dependencies chosen with support horizons in mind, and a support period decided with the finance director present.
The largest single improvement in that list is the security contact, which costs nothing. The most expensive is the flash provision on the next product, which costs very little if decided now.
Claims worth questioning
Security marketing is at least as confident as any other kind. A few claims recur:
- “Military-grade encryption.” Not a thing. Encryption algorithms are public and standard; what matters is key management, protocol design and implementation, none of which this phrase addresses.
- “Certified secure.” Certification attests to an assessment against defined criteria at a point in time. It is not a property of the product thereafter, and the scope of what was assessed matters more than the certificate.
- “Our device makes your plant compliant.” No product does. Industrial security frameworks apply to systems and the organisations operating them.
- “Blockchain secures the data.” Whatever a distributed ledger does, it does not address the security of a device, its firmware or its update path, which is where the exposure actually is.
- “No known vulnerabilities.” True of everything nobody has examined. The useful question is whether anyone has looked and what they found.
- “Air-gapped, so it cannot be attacked.” Genuine air gaps are rarer than believed, and maintenance laptops, removable media and temporary connections have defeated many of them.
The test worth applying to any supplier, us included: ask how long they will provide security updates, how you will be told about a vulnerability, and what happens at end of support. Specific answers indicate an organisation that has thought about it; vague ones indicate the opposite.
A short glossary
| Term | Meaning |
|---|---|
| Software bill of materials | A list of the components firmware is built from, including third-party libraries. Answers “are we affected” quickly. |
| Secure boot | Verification of firmware authenticity before execution, anchored in immutable storage. |
| Root of trust | The element that cannot be changed and that everything else’s trustworthiness derives from. |
| Coordinated disclosure | An agreed process between a finder and a manufacturer for handling and publishing a vulnerability. |
| Actively exploited | A vulnerability being used against real systems, not merely known. Generally triggers short reporting deadlines. |
| Support period | The declared duration for which security updates will be provided. A commitment, not an estimate. |
| Zones and conduits | The industrial framework’s way of describing security boundaries and the controlled paths between them. |
| Security level | In the industrial framework, the capability of attacker a system is intended to withstand. |
| Compensating control | A measure addressing a risk that cannot be fixed directly, such as segmenting an unpatchable device. |
| Provisioning | Installing identity and keys into a device, usually in manufacturing. A security-sensitive production step. |
| Key rotation | Moving to a new key. Must be provided for in advance or it is unavailable when needed. |
How we help with this
We work on the engineering that these obligations rest on: secure design and firmware, update mechanisms that survive interruption and can be recovered, generating bills of materials from the build, dependency monitoring, and documentation supporting a conformity claim. Where a product already exists, the assessment of what is in the field and whether it can be updated is usually the first useful piece of work.
We do not issue certifications, we are not a notified body, and we do not advise on whether a regulation applies to your product or how it should be classified. That needs a qualified adviser, and we would expect to work alongside one rather than in place of them.
Related reading: device security and OTA updates for the engineering practice, embedded firmware practice for reproducible builds and long-term maintainability, CE, UKCA and FCC certification for the wider conformity process, and OT/IT integration for boundaries in industrial systems. For the wider picture, what industrial IoT actually is.
If you take one thing away
Ask one question about your current products: could you get a firmware fix onto a device you shipped three years ago, this week, without a site visit?
If the answer is yes, most of what these regimes require is process and documentation around a capability you already have. If it is no, nothing else in this article is achievable for that product, and the only remedies are compensating controls, a replacement programme or an accepted risk. That question, asked honestly, tells you more about your exposure than any assessment document.
Questions we are asked about this
What clients ask before starting
Does the Cyber Resilience Act apply to us?
It applies broadly to products with digital elements placed on the EU market, which covers most connected hardware and a good deal of software, with heavier requirements for categories judged more critical. Whether and how it applies to a specific product depends on what the product is and how it is classified, and obligations phase in over a period. It is worth confirming the current position and your classification with someone qualified rather than relying on a summary, including this one.
What is a software bill of materials for?
It lists what your firmware is actually built from, including the libraries you did not write. Its value is practical rather than administrative: when a vulnerability is announced in a common library, an organisation with bills of materials can answer within minutes which products are affected, and one without spends days guessing. Most firmware contains far more third-party code than its authors remember.
How long do we have to support a product?
There is no single universal number. The direction of regulation is that you must state a support period and honour it, with expectations that it should be appropriate to the product — and for industrial equipment with a fifteen-year service life, a two-year support period invites obvious questions. The harder question is usually commercial rather than legal: supporting a product means keeping a build environment, signing capability and people who understand the code, for as long as you promised.
Is IEC 62443 something we need to certify against?
Certification exists and is required by some customers, particularly in energy and process industries. For many suppliers the more useful approach initially is to use the framework to structure the work — understanding the zone and conduit model, and what capability level a customer expects — rather than pursuing certification before anyone has asked for it. If a tender requires it, that changes the answer.
We sell business to business. Do consumer standards matter?
Frequently yes, indirectly. Baseline expectations such as no universal default passwords, a published route to report vulnerabilities and a stated support period increasingly appear in procurement questionnaires regardless of sector, because buyers have adopted them as a checklist. Meeting the baseline is inexpensive if designed in and awkward to retrofit.
What happens if a vulnerability is found in our product?
You need a route by which someone can tell you, a process for assessing and fixing it, a way to deliver the fix to devices in the field, and — where a vulnerability is being actively exploited — reporting obligations with deadlines measured in hours rather than weeks. The part most often missing is the delivery mechanism: knowing about a problem you cannot fix remotely is a considerably worse position than not knowing.
Does this apply to products we already sell?
Regulation generally applies to products placed on the market after a given date, but existing products are not unaffected: substantial modifications can bring a product into scope, customers ask about fielded equipment, and a vulnerability in a product still in service remains your problem commercially whatever the legal position. Establishing what you have in the field, and whether it can be updated, is worth doing regardless.
What do you actually provide?
Secure design and firmware work, update mechanisms that can be relied on, bills of materials and dependency monitoring, vulnerability handling processes, and documentation supporting a conformity claim. We do not issue certifications, we are not a notified body, and we do not give legal advice on whether a regulation applies to your product or how to classify it — for that you need a qualified adviser, alongside whom we would expect to work.
Could you update a product you shipped three years ago?
Tell us what you have in the field, whether it can be updated remotely and what your customers are starting to ask for. That is usually enough to say where the real exposure is.