Build Once, Submit Everywhere: MedTech Cybersecurity Across FDA, EU MDR and NHS DTAC 

Selling a software-enabled medical device into more than one market means answering to more than one regulator, and each asks for cybersecurity evidence in a different shape. The FDA wants a threat model with penetration testing mapped to it and a security risk management report. The EU wants that same evidence folded into your ISO 14971 risk file. The NHS wants a shorter, blunter assessment that starts with whether you hold Cyber Essentials. The engineering underneath is largely the same. The packaging is not. 

Treat the three as separate projects and you will build the same evidence three times, at three times the cost, with fresh delays and rework at every submission. Build it once, in a form you can repackage, and a second or third market becomes a mapping exercise rather than a fresh start. This article is for founders and regulatory leads at SaMD (Software as a Medical Device) companies with more than one market on the roadmap, particularly where the US and EU come first and the NHS is a later possibility. 

Why this matters now

The FDA reissued its premarket cybersecurity guidance on 3 February 2026. Under Section 524B of the FD&C Act, a cyber device submission needs a threat model, an SBOM (software bill of materials), and penetration testing that’s one of ten listed testing and analysis activities (alongside fuzz testing, attack surface analysis, and static and dynamic code analysis, among others), tested against a production-equivalent configuration, not an early prototype. Findings get mapped back to the threat model, and the whole thing is typically documented in a security risk management report reviewers can audit. 

EU MDR asks a structurally different question. The General Safety and Performance Requirements (GSPR) 17.2 and 17.4 call for state-of-the-art software lifecycle security and minimum IT security requirements, with MDCG 2019-16 expecting security risks folded directly into the ISO 14971 risk file rather than sitting in a separate cybersecurity document. It’s less about a standalone security document and more about proving security was managed as a clinical risk. 

NHS DTAC is different again. Version 2.0 landed on 24 February 2026, a quarter shorter than the previous form, with duplication against the Data Security and Protection Toolkit and the Pre-Acquisition Questionnaire removed. The technical security domain (C3) leans on Cyber Essentials, the DSIT Software Security Code of Practice, and external penetration testing. It’s genuinely a lighter bar than FDA or EU MDR for cybersecurity specifically. But it’s still mandatory, still pass/fail, and the old form stopped being accepted from 6 April 2026, so it isn’t standing still either. 

What actually differs 

Market	What they’re really checking	Evidence format
FDA 510(k)	Deep, ongoing engineering tied to a threat model	Threat model, ten test activities, SBOM, security risk management report
EU MDR	Security managed as a clinical risk	GSPR 17.2 and 17.4 folded into the ISO 14971 risk file
NHS DTAC	A baseline commercial pass/fail gate	Cyber Essentials, DSPT, a DTAC form

What's reusable, and what isn't 

The bulk of the work is reusable: the threat model, the SPDF, the core penetration test evidence, the SBOM, the secure update process. What’s market-specific is mostly packaging and a handful of certifications: the security risk management report FDA wants, the risk-file integration EU MDR wants, Cyber Essentials for NHS DTAC, and the cadence each market expects for retesting. Build the deep evidence once, and each market becomes a repackaging exercise rather than a new project. 

A pattern we see often: a SaMD company building an AI-assisted diagnostic platform, with the US and EU as priority markets and NHS interest still open, asked us directly whether our FDA and EU experience ran as deep as our NHS work. The honest answer mattered more than a reassuring one: NHS engagements are typically shorter and less stringent for cybersecurity specifically, FDA and EU MDR work is where we become an embedded, weekly partner. The useful reframe wasn’t really about our experience. It was about their architecture: build once, in a way that’s ready for whichever market comes next. 

How far each core artefact travels

It helps to be concrete about what reusable actually means. Across the engagements we run, roughly 70% of the core evidence carries across all three markets with only minor tailoring. The table below takes the artefacts that procurement teams, notified bodies and FDA reviewers ask for most often, and shows what stays the same and what you re-cut for each market. 

Core artefact	How it travels across FDA, EU MDR and NHS DTAC	Typical refresh cadence
Security architecture and boundaries	One boundary and data-flow diagram serves all three. FDA calls it Security Architecture and Architecture Views, EU MDR expects it inside the technical documentation, and DTAC C3.4 relies on it as secure-by-design evidence.	On any significant design change.
Threat model and risk register	The same threat model underpins every market. FDA ties it to the Section 524B reasonable-assurance standard, EU MDR folds it into the ISO 14971 risk file, and DTAC treats it as core C3.4 evidence.	Per major release.
Risk-control traceability matrix	One table linking each threat to its control, verification method and evidence location works everywhere, and it is what reviewers actually audit.	Quarterly review.
SBOM (software bill of materials)	Built once per release. FDA explicitly requires it for cyber devices, EU MDR finds it helpful for component transparency, and NHS procurement increasingly asks for it.	Every release, with vulnerability monitoring ongoing.
Security test evidence (penetration testing)	One well-scoped programme feeds all three. DTAC C3.3 wants an external test summary from the last 12 months covering the OWASP Top 10 (the most common web application risks), FDA wants findings mapped to your threat model, and EU MDR wants methods and results scaled to risk.	Annually, or on major change.
Secure update and patch policy	A single documented policy, covering delivery method and routine versus urgent timelines, satisfies all three markets.	Annual, plus on platform change.
Vulnerability disclosure policy (VDP)	One published disclosure route and triage process. Mandatory for many FDA cyber devices and widely expected by NHS buyers.	Quarterly review.
Post-market surveillance and monitoring	EU MDR sets the strictest bar, FDA requires a monitoring plan for cyber devices, and DTAC now expects a lightweight process. Build to the EU bar and the other two follow.	Ongoing.

Two free references go a level deeper on this mapping: our 10 Core Procurement Artefacts checklist, which sets out the minimum standard and market-by-market expectation for each artefact, and the Essential Guide to SaMD and MedTech Device Security. 

How to sequence it

• Build to the strictest bar you’ll realistically face first, usually FDA or EU MDR. Everything else gets easier from there. 

• Treat NHS DTAC as a repackaging exercise once the deeper evidence exists, not a parallel project running alongside it. 

• Keep your core architecture consistent across markets (APIs, deployment model) so your evidence doesn’t quietly fork into three different threat models. 

• Revisit the mapping whenever a market’s requirements update. DTAC v2.0 and the FDA’s reissued guidance landed within days of each other in February 2026. Markets move; your evidence plan should track them. 

Build the engineering core once, not the paperwork three times

The reason build once works is that the reusable core is engineering, not documentation. A Secure Software Development Lifecycle (SSDLC) builds security in from requirements through to post-market support, so vulnerabilities are found early, fixed cheaply, and evidenced as you go. In practice that means defining your security requirements alongside the clinical and functional ones, designing the system with clear trust boundaries and data flows, threat modelling with STRIDE (a structured way of asking what could go wrong: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege), then confirming the controls work with automated and manual testing before release. 

None of the three markets mandates a named SSDLC, but all three expect evidence of secure lifecycle development and risk management. The same backbone of standards supports every market: IEC 62304 for the software lifecycle, ISO 14971 for risk management, IEC 81001-5-1 for health-software security activities, ISO 13485 for quality management, and ISO 27001 for the security of your development environment. Anchor your processes to these once, and each market’s request becomes a mapping exercise rather than a rebuild. The teams that build to this standard from the start pass DTAC without scrambling and answer EU and FDA questions with evidence they already hold. 

Where this goes wrong

Building separate, shallower evidence for each market instead of one deep evidence base repackaged three ways. Treating NHS DTAC’s shorter 2026 form as licence to under-invest in security work you’ll need for FDA or EU MDR anyway. And letting architecture quietly diverge between markets, a region-specific data flow, a different deployment path, which forks your threat model without anyone deciding that on purpose. 

A few failure patterns show up again and again in real submissions, and they apply whichever market you start with: 

• Documented but unprovable. Excellent security that nobody wrote down. If a procurement team asks to see your architecture and you have nothing to share, the conversation ends quickly. Build your evidence index from day one, and document as you build, not after. 

• A broken traceability chain. The controls exist, but the documented line from threat to control to verification to evidence does not. To a reviewer, that is hard to tell apart from having done nothing. The chain is the evidence. 

• Threat model and SBOM treated as one-offs. Produced once during initial development, then left to go stale after a new release, cloud integration or API. Both need to be living documents, refreshed on every major change. 

• Patch commitments you cannot demonstrate. A policy that promises fixes in 14 days when reality has been months becomes a liability the moment procurement asks for proof. An honest, shorter commitment you can evidence beats an aspirational one you cannot. 

Free resources

Access to Markets, Key Differences and Overlaps: how cyber evidence compares across DTAC, EU MDR and FDA 510(k), the practical companion to this piece.

DTAC: The Three Phases of Readiness: useful if the NHS route is on your roadmap even as a secondary market.  

10 Core Procurement Artefacts: the artefacts procurement teams and reviewers ask for most, with minimum standard, market mapping and update cadence for each.

The Essential Guide to SaMD and MedTech Device Security: the full roadmap this article draws on, covering DTAC, EU MDR and FDA evidence end to end.  

Book a review

In 30 minutes, we’ll: 

1. Map your target markets against what each one actually expects 

2. Identify which parts of your existing evidence are already reusable 

3. Give you a straight sequencing recommendation for which market to build to first 

Get in touch

FAQs

Do we need three separate cybersecurity programmes for FDA, EU MDR and NHS DTAC? 

No. One properly built threat model, SPDF and penetration test programme can serve all three, repackaged to each market’s expected format. What changes is presentation and a handful of market-specific certifications, not the underlying engineering. 

Which market should we build evidence for first? 

Whichever has the strictest requirements you’ll realistically face, usually FDA 510(k) or EU MDR. Building to the higher bar first means the lighter NHS DTAC bar becomes a repackaging exercise rather than new work. 

Does NHS DTAC’s shorter 2026 form mean cybersecurity requirements got easier? 

No. Version 2.0 removed duplication with the DSPT and the Pre-Acquisition Questionnaire, which shortened the form, but the underlying Cyber Essentials and technical security expectations didn’t loosen, and the old form was retired from 6 April 2026. 

Can the same penetration test evidence serve more than one market? 

Largely, yes, if it’s scoped and documented well from the start. FDA specifically wants findings mapped to your threat model and a security risk management report in a particular format, so the packaging differs even when the underlying testing doesn’t. 

What if our architecture differs between regions, for example separate EU and US servers for data residency? 

That’s normal and doesn’t have to fork your evidence, provided the core application logic and security controls stay consistent. Document the regional difference explicitly in your threat model rather than letting it become an untracked divergence. 

How often should we revisit this mapping? 

Whenever a target market updates its framework (as both the FDA and NHS did within days of each other in February 2026) and after any material change to your product’s architecture. 

Related reading

• How do you pen test a device that isn’t on the network?: the companion piece on building representative security evidence for on-premises and air-gapped deployment models.  

• Hands-on or hands-off? Choosing how much of your MDR/510(k) work to outsource: how much delivery support to bring in, once you know which markets you’re building for.

• Adaptix case study: a worked example of a connected medical device manufacturer taken through FDA 510(k), and subsequently into the EU and NHS.