EmberKat

Environment

When the software is the product, and someone else sets the requirements

Three conditions usually travel together. Where they hold, the same engineering discipline applies — regardless of which industry the company is in.

Book 30 minutes
Requirements, software changes, tests, imaging validation, release evidence and monitoring form one inspectable digital lineage.
01

The software is the product, not a tool supporting one.

02

External parties impose requirements on it — customers, auditors, or law.

03

A mistake has consequences outside the bug tracker.

01 // Where this applies

Two conditions, and neither one is company size

This discipline comes from regulated medical software, which had to take it seriously decades before anyone else. It applies wherever the conditions match.

The environment

Ordered by where the pressure is actually felt.

  • B2B software vendors whose buyers impose security requirements The requirement arrives from a customer, with a deadline and a signature attached to it.
  • Companies selling into regulated sectors Health, finance, public bodies. You inherit your customer’s obligations without having a regulator of your own.
  • Regulated medical software and the clinical systems around it Where the depth was built. Named as experience, not as the only market.

The organisation

This is where smaller companies qualify.

  • There is no internal person who could own this Not negligence. The role simply is not justified yet.
  • A decision is needed, not another assessment Someone has to say “yes, this way” and be accountable for having said it.
  • The requirement already arrived And the answer has to survive a knowledgeable questioner, not just fill a field.

02 // Why now

Two legally distinct pressures, arriving as one pile of questionnaires

Most vendors have not separated them. Separating them is the difference between answering procurement quickly and rebuilding the same argument every quarter.

Direction one — your customer’s duty

NIS2 Article 21(2)(d) obliges essential and important entities to manage supply chain security, explicitly including the cybersecurity practices and secure development procedures of their suppliers.

Healthcare providers are in scope. A hospital discharges that duty through procurement — questionnaires, contract clauses, requests for SBOM and VEX. A vendor receives it as a condition of sale, not as regulation.

Direction two — your own product duty

The Cyber Resilience Act places requirements directly on products with digital elements placed on the EU market, independently of who buys them.

Same artefacts, different legal source. Knowing which is which tells you what is negotiable in a contract and what is not negotiable at all.

The correction most vendors need

The CRA requires a manufacturer to have an SBOM, not to publish one. Annex I Part II(1) asks for a machine-readable bill of materials covering at least top-level dependencies. Recital 77 says manufacturers should not be obliged to make it public — it belongs in the technical documentation and goes to market surveillance authorities on request under Article 53. So when a hospital asks a vendor for an SBOM, that request traces to NIS2 and procurement, not to the CRA.

03 // What actually goes wrong

Four failure modes, and none of them is a missing policy document

01

A buyer’s security questionnaire arrives, and the team reconstructs the reasoning behind decisions made two years ago.

Cost: The answer is defensible only as far as memory reaches — and the reconstruction repeats at every deal.

02

A CVE lands in a dependency. Nobody can say which shipped versions contain it, or which customers are running them.

Cost: Disclosure becomes a research project at the moment a customer has already asked, with a deadline.

03

An assessment produced two hundred findings. Nobody internally can act on them, because they trace to neither causes nor owners.

Cost: The list is reported as risk every quarter and closes at the rate of nothing.

04

An external requirement is answered with a policy document while the architecture stays exactly as it was.

Cost: It passes the paperwork and fails the first technical question — and buyers increasingly send an engineer.

04 // What you will be asked for

The artefacts, and which instrument creates the duty

The fourth column is the part most vendors have never separated: two different legal sources converge on the same artefact for different reasons.

Lifecycle phase against artefact, owner, legal source and the failure it forecloses.
Phase What you will be asked for Who produces it Where the duty comes from What it forecloses
Architecture and decision Trust boundary and data-path description. A decision record with the criteria that produced it. Architect, or an external decision owner. MDR Annex I 17.2 / 17.4MDCG 2019-16 Customer questionnaires ask the same thing in commercial language. Reconstructing evidence after the fact.
Build and supply chain SBOM per build, machine-readable. Component provenance control. Delivery team — automatically, in the pipeline. CRA Annex I Part II(1)NIS2 Art. 21(2)(d) The CRA is why you hold it. NIS2, through the buyer, is why you are asked for it. “We don’t know what’s in it.”
Release Security requirements traceable to tests. A risk record a reviewer can follow without a guide. Release owner. IEC 62304EN IEC 81001-5-1CRA Annex I Part I — 11 Dec 2027 The requirement answered as a document.
Post-market VEX for released versions. A disclosure process with deadlines, and a reporting path that exists before it is needed. Product owner, with support. CRA reporting — 11 Sep 2026MDCG 2019-16 Reporting goes to ENISA and the national CSIRT. Disclosure as a research project.

These standards are the strictest reference system available. Where none of them applies to a company, these are still the artefacts a serious buyer asks for — which is what makes medical-domain depth useful well outside medicine.

Where a product contains AI, the same rows gain content rather than the table gaining a column. Data provenance at architecture, model components in the bill of materials, behaviour on model failure at release and post-market.

References

Every instrument named above, linked

Every date and clause reference comes from these texts, not from summaries of them. Where a claim does not match the source, the source wins.

  1. 01
    NIS2 — Directive (EU) 2022/2555

    Article 21(2)(d) is the supply-chain measure that reaches suppliers through their customers.

  2. 02
    CRA — Regulation (EU) 2024/2847

    Annex I Part I and Part II carry the essential requirements; Recital 77 and Article 53 are why the bill of materials is held rather than published.

  3. 03
    AI Act — Regulation (EU) 2024/1689

    The high-risk regime. Application dates were deferred by the Digital Omnibus agreement of 7 May 2026, which is why they are attributed rather than asserted above.

  4. 04
    MDR — Regulation (EU) 2017/745

    Annex I general safety and performance requirements 17.2 and 17.4 — development according to the state of the art, with IT security considered.

  5. 05
    MDCG 2019-16 Rev.1

    Commission guidance on cybersecurity for medical devices: risk management, security by design and default, across the whole lifecycle including post-market.

  6. 06
    IEC 81001-5-1:2021 paid text

    Security activities in the health software life cycle. Notified bodies treat the EN version as the route to demonstrating the MDR Annex I requirements above.

  7. 07
    IEC 62304 paid text

    The medical device software life cycle standard underneath it.

  8. 08
    Cyber Resilience Act — Commission summary

    The application timetable in plainer language than the regulation itself.

Links resolved 27 July 2026. Standards behind a paywall are marked; the EU instruments are free to read in full.

05 // What this looked like once

Two hundred findings were four problems

A group had acquired a subsidiary that manufactures medical devices. An assessment had produced a report nobody at the subsidiary could act on. Security there was not a department — it was one long-serving employee carrying it alongside another job, with no additional headcount.

Every finding traced back to four kinds of exposure, each generating dozens of separate entries. Remediation then ran on four different clocks: email authentication took hours, while separating production equipment from the internet was a planned change with downtime, agreed around a manufacturing schedule. Treating those as one backlog is what had kept the list frozen.

Everything in scope closed. What was deliberately accepted was written down with a reason rather than left open, so the next assessment starts from a decision instead of a gap.

06 // How this starts

Fixed scope is the door, not the destination

Most engagements begin with fixed scope, because the work should be judged before a relationship is committed to. What usually follows is the third option — the organisational condition at the top of this page does not resolve itself when the first report is delivered.

If you are assessing this as a supplier

Eitautas Šimaitis The practitioner who scopes the work, forms the recommendation, and stays through implementation.

The work is carried from scope to closure by the same named person. That is deliberate: you are buying judgment, and judgment does not improve by being routed through an account manager. That also makes continuity a fair question. It is answered in the engagement rather than left implied: what gets documented as the work proceeds, who holds a copy, and what happens to an active remediation programme if I am unavailable.

From the glossary

conformity assessment
The formal check that a product meets its legal requirements before it is placed on the market.
trust boundary
The line where information or control passes between parts of a system that do not trust each other equally.
IEC 81001-5-1
The security companion to IEC 62304: which security activities belong in each stage of a health software product’s life.
MDCG 2019-16
The European Commission’s guidance on how cybersecurity should be handled for medical devices.
remediation
Actually fixing what an assessment found — as opposed to recording it.
provenance
Where a software component came from, and whether that can be shown rather than assumed.
IEC 62304
The international standard for how medical device software is developed and maintained.
AI ActRegulation (EU) 2024/1689
The EU law on artificial intelligence. It sorts uses by risk and attaches obligations to the higher-risk ones.
ENISAEuropean Union Agency for Cybersecurity
The EU’s cybersecurity agency. Under the CRA, actively exploited vulnerabilities are reported to it.
CSIRTComputer Security Incident Response Team
The national body a serious security incident gets reported to. Every EU country has one.
NIS2Directive (EU) 2022/2555
An EU law that holds organisations in important sectors — health, finance, energy, transport, digital — responsible both for their own security and for checking their suppliers.
SBOMSoftware Bill of Materials
A list of every component inside a piece of software — an ingredients label, in a form a machine can read.
CRACyber Resilience Act, Regulation (EU) 2024/2847
An EU law that puts security requirements on the product itself — effectively anything containing software that is sold in the EU.
MDRMedical Device Regulation, Regulation (EU) 2017/745
The EU law covering medical devices, including software that is a medical device in its own right.
VEXVulnerability Exploitability eXchange
A statement of whether a known flaw in a component actually affects your product.
CVECommon Vulnerabilities and Exposures
A public reference number for a known security flaw — like a case number that anyone can look up.
The full glossary

Next step

Bring the situation

Thirty minutes, to work out whether I’m the right person for what you’re dealing with. Bring the affected system, who owns the outcome, and the deadline. No confidential reports, credentials or patient data in the booking form — we’ll agree a secure route first.

Book 30 minutes