Clearing a Class II WSI system: the 510(k) cybersecurity playbook

The device was a whole slide imaging system: a slide scanner, an acquisition workstation, an image management system, a zero-footprint viewer, a diagnostic display, and the interfaces that carry images and reports to the laboratory information system and the pathologists who sign out cases. In FDA terms it sits in 21 CFR 864.3700, Class II, special controls, product code PSY — an in vitro diagnostic device reviewed by the Office of In Vitro Diagnostics, and not eligible for third-party review.

The strategic context set the bar for everything that followed. The platform was already in the field, generating images for research use — a materially different claim from informing a diagnosis. A 510(k) carrying a clinical indication turned the same scanner, software and analytics into a diagnostic device, sold into hospital pathology departments and into a competitive set occupied by the established digital pathology players. Reviewers read that difference precisely: the imaging pipeline was unchanged, but its output now sat upstream of a diagnosis rather than a study, which raises the severity side of every scenario in the security risk assessment. Our threat model had to be written for the clinical claim, not for the installed base.

Two AI-enabled device software functions sat alongside that imaging chain: a specimen-detection model that found and localised tissue on the slide, and a diagnostic-assistance model that flagged regions with clinical implications for the pathologist to review. Neither was an ornament on the submission: the diagnostic module was the point of the exercise, the research platform’s analytics becoming a clinical claim. The diagnostic module sits outside the PSY definition altogether — that classification excludes automated image analysis that constitutes computer-aided detection or diagnosis — so it was routed as a software algorithm device to assist users in digital pathology under 21 CFR 864.3750, which carries its own cybersecurity content in its special controls. The security file had to serve both device types at once.

Because the platform has software, connects to a network, and carries technological characteristics that could be vulnerable to attack, it is also a cyber device under section 524B(c) of the Federal Food, Drug, and Cosmetic Act. That single classification changes the shape of the submission. Three cybersecurity deliverables stop being "recommended documentation" and become statutory content. And because 510(k)s must now be filed through eSTAR, an incomplete or inaccurate cybersecurity section does not earn you a polite deficiency letter — it earns a technical screening hold of up to 180 days.

What follows is the sequence we actually ran, compressed into something you can reuse. It assumes a Class II cyber device filed by a non-US manufacturer, but the logic holds for any connected device going through premarket notification.

Before the clock starts: capability vetting, then two days in a room

The engagement did not open with a document request. It opened with the client deciding whether we could do the work at all — a capability review run by their regulatory and quality leadership before scope was even discussed. They tested four things: depth in security risk management to AAMI TIR57 rather than general IT security; familiarity with IVD and digital pathology, including where whole slide imaging stops and an algorithm device begins; command of FDA premarket mechanics, eSTAR included; and whether we could work inside an existing quality system alongside in-house clinical experts and a separate FDA consultancy without duplicating or contradicting either. They wanted to see real artefacts and talk to the people who would do the work, not the people who sold it.

That vetting is where scope is actually set, which is why it deserves more attention than it usually gets. A consultancy that cannot describe the boundary between the security file and the ISO 14971 file will discover it in week ten, at the client's expense. The question to ask at this stage is the awkward one: when a security scenario implies patient harm, who writes the entry, and in whose document?

Then two full days on the device, in person, with the engineers who built it. Not a kickoff — a working session. The agenda ran: the architecture from scanner through acquisition workstation, image management, viewer, display, and out to the laboratory information system over HL7 and DICOM; the intended use and indications as written rather than as remembered; the two AI modules and precisely what each one claims to do, because that determines which regulation it sits under; the predicate position and the regulatory history; an inventory of evidence that already existed, from design controls to MDR technical documentation to earlier test reports; the state of the eSTAR; and the programme constraints, meaning the target submission date and every freeze upstream of it.

Two things came out of those two days that shaped everything after. The first was a device description everyone had agreed to, which became the first draft of the global system view — same boxes, same interfaces, argued once instead of five times. The second was an exclusion list written into the statement of work: the ISO 14971 file, the ISO 13485 audit trail, clinical evaluation, human factors validation, and predicate strategy all sat with the client and their FDA consultants. Naming what we would not do protected the schedule more than anything we promised to do.

By the end of day two we could price the work honestly and name the three questions that would need a Pre-Submission. Both of those are worth two days.

Answer the statutory question before you open a document list

Before anyone writes a work instruction, settle whether the device is a cyber device. The test is three-pronged and cumulative: does it include software validated, installed, or authorised by the submitter as a device or in a device; can it connect to the internet; does it contain technological characteristics that could be vulnerable to cybersecurity threats. A scanner that pulls patches from a vendor server and serves images to a viewer over a hospital network satisfies all three without argument.

That answer triggers section 524B(b), which requires the sponsor to submit:

1. a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure and related procedures;
2. evidence of processes and procedures that give reasonable assurance the device and related systems are cybersecure, plus the ability to make postmarket updates and patches available;
3. a software bill of materials covering commercial, open-source, and off-the-shelf components.

Three obligations, and each maps to a document you have to be able to point a reviewer to by page number. We built the project plan around those three plus the guidance's own documentation set, and nothing else got funded without a trace to one of them.

Choose the predicate with cybersecurity in the room

Substantial equivalence turns on intended use and technological characteristics. Cybersecurity does not appear in the statutory test, and that leads some teams to assume a security-weak predicate lowers the bar. It does not. Section 524B applies to your submission regardless of what your predicate did, and the reviewer assesses your security posture against the guidance on its own terms.

We still built a predicate comparison table, with a cybersecurity row. It did two useful things: it forced the engineering team to articulate where the platform genuinely differed from the cleared devices (cloud-hosted image management, remote service access, a new display firmware stack), and it gave us a defensible answer when the reviewer asked why a particular control appeared only in our device. If a difference raises a new question of safety or effectiveness, you want to know that in month two, not in an Additional Information letter.

One wrinkle specific to this engagement: a platform already installed under research-use labelling can create a false sense of security, because the device is visible in the market. It is not a substantial-equivalence argument, and a research-use statement does not survive a diagnostic indication. The comparison had to be built as though the device were new — because for the clinical claim, it was.

Use a Pre-Submission for the architectural questions you cannot guess at

A Q-Submission is optional and costs calendar time, so it has to earn its place. Ours did, on three questions that would have been expensive to get wrong: where the device boundary sat relative to the hospital and laboratory information system interface and to image storage held at the customer’s site; how to document a multi-site deployment where the customer supplies the network; and what level of detail FDA wanted for a scanner firmware update path that traverses customer infrastructure. PreSTAR is available for Q-Submissions now, which makes the logistics lighter than it used to be.

Ask narrow questions with your own proposed answer attached. A pre-sub that asks "is our cybersecurity documentation adequate" gets a non-answer and burns eight weeks.

Run a gap assessment against the guidance, not against a template

The temptation is to buy a 510(k) cybersecurity template and fill in the blanks. We did the opposite: a clause-by-clause traceability matrix from the guidance to our existing evidence, scored as present, partial, or absent. A few hundred rows, which sounds grim, and it took the better part of a month for two of us. It is the single highest-leverage artefact of the whole programme, because it becomes the submission's index later and because it surfaces the uncomfortable gaps early.

Two structural decisions came out of that matrix. First, the security work had to sit inside the client's quality system rather than beside it: the secure product development framework lives in design controls, and with the Quality Management System Regulation effective from 2 February 2026 and incorporating ISO 13485:2016 by reference, their existing certification and design-control records were the right home. That system belonged to the client's quality organisation and their FDA consultants, not to us. Our job was to produce security evidence that slotted into it at the points where TIR57 touches design controls, and to state plainly which of our artefacts were now records they had to control, retain, and audit. Second, we treated the guidance's appendices as normative. They are part of the recommendations, not background reading.

The security objectives we designed against

Authenticity and integrity, authorisation, availability, confidentiality, and secure and timely updatability and patchability. Every architecture decision had to argue its contribution to one of those five. In a diagnostic imaging system the integrity objective carries unusual weight: an attacker who can alter an image, or the metadata that identifies which case it belongs to, has not stolen data — they have corrupted a diagnosis.

Build the security risk file: threat model first, exploitability second

This is where most submissions are thinnest, and where reviewers spend their attention. Two distinct activities, often conflated.

Threat modelling. We have a proprietary threat modelling framework and use it by default, but for this engagement we used Microsoft’s STRIDE, and the reason is worth stating plainly. FDA expects a recognised methodology, submitted with a rationale for the choice, and a reviewer has to be able to follow the model without a briefing on your house method. STRIDE applied per element across the system’s interfaces gave us that: a taxonomy the reviewer already knows, used consistently, with the depth of our own framework showing up in the analysis behind it rather than in a bespoke notation nobody else can read.

Whatever method you pick, the guidance is explicit about what the model must do: identify risks and mitigations, state assumptions about the environment of use (a hospital network is hostile; assume an adversary controls the network and can alter, drop, and replay packets), and capture risks introduced through supply chain, manufacturing, deployment, interoperability, maintenance, and decommissioning. That last clause is what a conventional safety risk analysis misses, and it is exactly where a WSI system accumulates exposure: a service laptop, a distributor's imaging workstation, a decommissioned scanner with patient images still on disk.

Risk assessment. Cybersecurity risk is not assessed with probability. There is no defensible likelihood estimate for a motivated human actor, so the guidance directs you to exploitability and severity of patient harm, pre- and post-mitigation, with documented scoring method and acceptance criteria. We used a CVSS-informed exploitability rating crossed against a harm severity scale, with a binary controlled/uncontrolled determination per scenario — the same binary discipline the 2016 postmarket guidance recommends for vulnerability triage.

Three rules we enforced and would enforce again:

• Known vulnerabilities are reasonably foreseeable risks. Anything on CISA's Known Exploited Vulnerabilities list must be designed out, not assessed and accepted.
• Security and safety risk management are separate but coupled. AAMI TIR57 and ANSI/AAMI SW96 describe the interface, and TIR57 was the standard we worked to from start to finish. We produced the security side of that interface as an explicit handoff: every security scenario with plausible patient-harm potential, with its severity reasoning and the controls in place, formatted for the clinical team to enter into the ISO 14971 file. They owned the safety file and made those entries; we did not. The handoff ran both ways — where a safety control introduced a new security weakness, it came back to us for assessment.
• Risk transfer requires communication. If you push residual risk to the user, the information must be complete, assessed, and in the labelling — including what happens at end of support, and whether the user can realistically take that role on.

Produce the four architecture views — for a WSI system they are not abstract

Four view types are expected, each with diagrams plus explanatory text, each traceable to security requirements. For an imaging platform they mapped onto real, arguable architecture decisions.

Where one view already captured another's content we said so rather than duplicating diagrams, which the guidance permits. What we did not do was omit a view without explanation; that is treated as a gap, not an editorial choice.

Intended use is a boundary instrument

The most consequential architectural argument of the engagement was not a control but a definition. The intended use set the system boundary, and it placed two things deliberately outside it: integration with the hospital and laboratory information systems, and storage of processed images at the customer’s own location — on-premises or in the customer’s cloud tenancy. The device is responsible for transferring images securely to those destinations: authenticated channels, encryption in transit, integrity protection on the payload. It is not responsible for what happens to them afterwards.

That line has to be written down, drawn, and defended in three places at once — the intended use and indications for use, the global system view, and the labelling, where the user’s side of the responsibility is stated. It also has to survive contact with the threat model: an interface outside the boundary is still an attack surface, so the controls on it were assessed even where the resulting harm would land in a system the manufacturer does not own. Where the boundary was arguable we put it to FDA in the pre-submission rather than discovering the disagreement in review. Getting it wrong is expensive in both directions — too wide and you have taken on responsibility for a hospital’s storage estate, too narrow and you have under-analysed an interface your product depends on.

Get the SBOM right, and treat it as a living artefact

The SBOM is the only one of the three 524B deliverables named explicitly in the statute, and it is where reviewers ask the sharpest questions. Ours was machine-readable, in a recognised format, consistent with the NTIA minimum elements, and complete to transitive dependencies — more than 2,300 components once the container base images, the DICOM and colour-management libraries, the database, and the embedded OS were unpacked. Where a supplier would not disclose sub-dependencies, we documented the depth limitation and the justification rather than quietly truncating.

Two things that are easy to miss and expensive to retrofit:

• Support information per component. For each component, the level of support the supplier provides through monitoring and maintenance, and the end-of-support date. A medical device with a decade-long service life built on components that go end-of-life in three years is a labelling problem, a postmarket problem, and a reviewer question all at once.
• A vulnerability assessment that travels with it. For each known vulnerability: safety and security impact on the device and system, and the controls that address it. This can live outside the SBOM file itself — keeping the SBOM machine-ingestible is worth the separation — but it must be in the submission.

Triage is where SBOM work either moves or stalls. We ran the SBOM through VASE — our own in-house tool at the time, provided to the client's team for the engagement rather than operated as a SaaS platform — for component vulnerability analysis and prioritisation, so engineering received a ranked queue instead of a flat list of CVEs against 2,300 components. That ranking is what let the team remediate third-party libraries at a pace that fitted the submission timeline, rather than triaging in inventory order for a month. The same analysis fed the vulnerability assessment that travels with the SBOM, so one body of work served both the engineers doing the fixes and the reviewer reading the file. Running it in-house rather than through a hosted service also kept the ranking alongside the client's own SBOM and support records, which is where a reviewer looks for it.

The legacy-OS problem is real and worth naming. Scanner control software often sits on an embedded Windows build chosen for hardware compatibility and frozen years earlier. Our answer was not to hide it: we documented the compensating controls (network segmentation, restricted egress, application allow-listing, signed update channel), put a dated remediation plan in the cybersecurity management plan, and disclosed the constraint in the security implementation guide so integrators could act on it.

Test to the claims you made, at system level, with credible independence

Four testing categories are expected: security requirements testing, threat mitigation testing, vulnerability testing (scanning and analysis), and penetration testing. The report has to show scope, method, findings, and retest — and the testers' independence and technical expertise have to be defensible.

The penetration testing followed published checklists rather than a bespoke plan: the OWASP Web Security Testing Guide for the web-facing applications and services, and NIST SP 800-115 for the technical security testing and assessment process around it. Naming the standard matters as much as following it, because it lets a reviewer see what was covered and what was not.

Testing also ran in rounds rather than once. The first pass found issues, engineering fixed them, we retested, and a second and third round followed as the fixes landed and the code moved. Each round produced its own report and each finding carried a disposition, so the final evidence is a dated sequence rather than a single snapshot taken at the end. Sponsors who test once and late end up choosing between shipping unfixed findings and reopening the file.

For this device the productive attack surface was not the web viewer. It was the parsers. DICOM and HL7 interfaces are string-processing code facing an untrusted network, and a malformed image header or message is a plausible path to a scanner or an image management service. We ran protocol fuzzing alongside conventional network and application testing, and we tested the update path itself — signature verification, downgrade resistance, rollback behaviour — because the patch channel is the one control that, if broken, invalidates every other one.

Two models, one more device boundary, and a change-control problem

The models changed the cybersecurity work in five places, and each one is worth planning for if your platform carries AI.

Boundary. An inference service is a system element, not a feature. Where the model runs, who is allowed to call it, what it returns, and how the result is written back into the case all became named elements and interfaces in the global system view and the threat model. The diagnostic module added a second device boundary to argue about, because the algorithm device's special controls at 864.3750 already require a system-level architecture diagram with communication endpoints, protocols, and security protections, plus a risk management plan covering third-party software and service vulnerabilities. Most of that document was reusable as 524B evidence. The work was the mapping, not the writing.

Integrity, specifically. For an imaging platform, image integrity is the control that matters. For an AI module, model integrity joins it. Model artifacts were signed, hashed, and verified at load, and the inference service was designed to fail closed: a model that cannot be verified does not load, and the pathologist is told the assistive function is unavailable rather than being shown an overlay produced by something else. We tested that explicitly — substituted artifact, corrupted artifact, downgraded artifact — and the fail-closed behaviour went into the test report as evidence against a threat we had modelled.

SBOM depth. The model runtimes and their dependencies — inference engine, GPU libraries, numerical stack — are ordinary components with ordinary support dates, and the model artifact itself was recorded with version and hash. The uncomfortable finding was the support horizon: GPU runtime libraries age faster than a ten-year device life, and the component most likely to reach end of support before the platform does was in the AI path, not the imaging path. That went into the support-date register and into the cybersecurity management plan as a scheduled review.

A PCCP, because your roadmap is the real threat to your clearance. A device with two models will be retrained. The predetermined change control plan is the mechanism that lets planned modifications ship without a new submission — description of modifications, modification protocol, impact assessment. The cybersecurity half of that document is the update path: signed distribution, version pinning, rollback, and evidence that a rolled-back model is the model you think it is. Writing the PCCP after clearance means every retrain becomes a submission decision made under pressure.

Labelling. The AI functions, their versions, what the update channel will deliver, and what the user must do when a model update changes outputs. The 864.3750 labelling requirements already ask for instructions on resolving device-related issues including cybersecurity ones, so the two obligations converged rather than competed.

Write the labelling as an operational document, not a disclaimer

Transparency is a review criterion, not an afterthought. Users need enough information to install the device, integrate it, and keep it secure through its life. For a hospital-deployed imaging platform that meant two documents with different audiences: the instructions for use, and a security implementation guide aimed at the biomedical engineering and IT teams who will actually segment the network and schedule the patches.

Content that had to be there: a unique device cybersecurity identification, the system's interface inventory, network and firewall requirements, account and authentication expectations, backup and restore, the update mechanism and its cadence, the end-of-support statement, a statement of where the device boundary ends relative to the LIS/HIS interface and customer-owned storage, and the residual risks the user is expected to control.

One useful convergence: 21 CFR 864.3700 already requires a human factors engineering process for the system's user interfaces, and that sat with the client's clinical and human factors team. We supplied the cybersecurity labelling content plus the specific tasks we needed validated — segmenting the network, verifying a signed update, responding to a failed model load — and they folded those into their existing validation rather than commissioning a separate study. Cheaper, and a stronger position than testing the words in isolation.

Write the cybersecurity management plan for the next ten years

This is the 524B(b)(1) deliverable, and reviewers read it as a commitment rather than a description. Ours specified: the monitoring sources (supplier advisories, NVD, CISA KEV, sector intelligence, customer reports); the triage method and the exploitability-severity matrix used to decide controlled or uncontrolled; the coordinated vulnerability disclosure process and the contact route, aligned with ISO/IEC 29147 and 30111; the patch development and release timelines by severity; the cadence of periodic security testing; the metrics tracked; and the roles accountable for each step.

It also had to connect to the regulatory machinery that activates after clearance: corrections and removals under 21 CFR 806, medical device reporting under 21 CFR 803, and the routine-update distinction from the 2016 postmarket guidance, which lets security patches that do not reduce an uncontrolled risk of harm ship without a new submission.

Assemble the eSTAR cybersecurity section — and respect the accuracy trap

Since 1 October 2023 all 510(k)s, unless exempt, must be filed as electronic submissions using eSTAR. Because this is an IVD, the IVD eSTAR applies. The cybersecurity section is not a document dump; it is a set of specific attachment requests plus structured questions, and several of them demand page numbers into your own documents for traceability.

The trap is the structured answers, not the attachments. A dropdown answered inaccurately — for instance indicating that cybersecurity does not apply, or misdescribing a component — suppresses subsequent questions and produces an internally inconsistent eSTAR. Technical screening catches that, and the submission goes on hold for up to 180 days. Two practical habits: have a second person read every cybersecurity dropdown against the attached evidence, and build a PDF with bookmarks and a table of contents rather than submitting forty separate attachments. Do not password-protect anything; it interferes with redaction of confidential commercial information.

Submit, then manage the clock and the deficiency letter

The timelines are published and worth planning against rather than hoping about. FDA communicates acceptance within 15 calendar days — for an eSTAR that passes technical screening, acceptance dates from receipt. A substantive interaction is due within 60 calendar days for 95% of submissions. The decision goal is 90 FDA days for 95% of 510(k)s, with an average total time to decision target of 112 calendar days for FY2025–2027 submissions.

We received one Additional Information letter. Its cybersecurity content was narrow: support-level evidence for two third-party components, and a request to clarify the boundary of the cloud-hosted image management service in the global system view. Both were things our gap matrix had flagged as partial and we had chosen to argue rather than fix. That is the honest lesson — the matrix was right, and the argument cost more than the fix would have.

The response was an amendment that stopped the review clock, which is why the calendar discipline matters upstream: an AI letter in week eight of the review is a different problem from an AI letter in week two.

Plan the change control before you need it

Clearance is a milestone, not an exit. The guidance's modifications section sets out how much cybersecurity documentation a subsequent submission needs, scaled by whether the change is likely to affect cybersecurity, and the least-burdensome principle applies. In practice this means your change-control procedure needs a cybersecurity impact question with defined answers, so that a viewer update, a new cloud region, a cryptographic library upgrade, and a new scanner model each route to the right level of documentation without a debate every time.

We left the client with a decision tree: routine update under the postmarket guidance; new 510(k) with full cybersecurity content; new 510(k) with reduced content and a justification. Plus a standing rule that the SBOM, the support-date register, and the vulnerability assessment are regenerated on every release, not on every submission.

Model releases sat above that tree rather than inside it: planned modifications within an authorised predetermined change control plan, and anything outside it back through the submission route. That is the line the client's engineering roadmap will test first, because retraining is cheap and the regulatory decision around it is not.

Effort against calendar

The distribution of effort matters more than the total, because the front half is where the leverage sits. Read the table below as effort in working weeks, with workstreams overlapping rather than running in sequence — not as elapsed calendar time, which is a different and longer number.

Seven things we would tell the next team

• Spend two days on scope before you spend a day on documents. A working session with the engineers that ends in one agreed device description and a written exclusion list is worth more than any template, and it is the only reliable way to price the job.
• Treat the security risk file as the spine. Every other security artefact — views, SBOM, testing, labelling — is either an input to it or an output from it. Teams that treat them as parallel deliverables produce submissions where the pieces contradict each other, and reviewers find the contradiction.
• Do not use probability for cybersecurity risk. It is the single most common substantive deficiency we see in other sponsors' files, and it signals a safety file with a cybersecurity chapter bolted on.
• Fix the SBOM plumbing early. Generating a machine-readable SBOM from your build system, with support dates maintained in a register, is a tooling problem. Discovering it in week twenty-two turns it into a project risk.
• Fuzz the parsers. For imaging devices the interesting vulnerabilities live in DICOM, HL7, and file-format handling, not in the login form.
• Rehearse the dropdowns. Technical screening holds are almost always caused by structured answers that do not match the evidence, not by missing attachments.
• Write the labelling for the biomedical engineer who will install it. A statement that the user must "ensure appropriate network security" transfers nothing useful and reads as evasion.

The European leverage, if you are filing from outside the US

The client's in-house teams and their FDA consultants had already built the MDR technical documentation, including a security risk assessment under MDCG 2019-16, a secure development process aligned with IEC 81001-5-1, and an ISO 14971 file. We did not audit any of it — that was outside our remit — but we built on top of it, and from where we sat almost none of it was wasted. The FDA expectations are more prescriptive about the four architecture views, about SBOM depth and support dates, and about exploitability-based assessment. The underlying evidence transferred, and the differences were a mapping exercise rather than a rebuild.

The direction of travel helps too. With the Quality Management System Regulation now aligned to ISO 13485, a European quality system maps to FDA expectations far more directly than it did under the old quality system regulation — a point the client's own regulatory consultants were already exploiting — and the same security engineering work is increasingly reusable across MDR, FDA, and the obligations arriving under the EU Cyber Resilience Act. The sensible posture is one security file, several regulators, and a submission assembly step per market rather than a re-engineering step per market.

Sources and further reading

• FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final guidance, February 2026; supersedes the June 2025 edition).
• FDA, Cybersecurity in Medical Devices: Frequently Asked Questions, including the section 524B requirements.
• FD&C Act section 524B, Ensuring Cybersecurity of Devices, added by section 3305 of the Consolidated Appropriations Act, 2023.
• FDA, Postmarket Management of Cybersecurity in Medical Devices (final guidance, December 2016).
• FDA, eSTAR Program, including current template versions and technical screening policy.
• FDA, Premarket Notification 510(k).
• FDA, MDUFA Performance Goals and Procedures, Fiscal Years 2023–2027, section II.F on 510(k) timelines.
• 21 CFR 864.3700, Whole slide imaging system; product code PSY.
• 21 CFR 864.3750, Software algorithm device to assist users in digital pathology, including the special controls on system architecture and cybersecurity risk management.
• FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions (final guidance, December 2024); read alongside the AI-enabled device software function lifecycle and marketing submission guidance (January 2025).
• FDA, Quality Management System Regulation (21 CFR part 820), effective 2 February 2026, incorporating ISO 13485:2016.
• ISO 13485:2016 and ISO 14971:2019, the quality management and risk management standards the client's own teams worked to.
• CISA SBOM programme, including the NTIA minimum elements for a software bill of materials (October 2021).
• CISA Known Exploited Vulnerabilities Catalog; NIST National Vulnerability Database.
• Microsoft STRIDE threat model; OWASP Web Security Testing Guide; NIST SP 800-115, Technical Guide to Information Security Testing and Assessment.
• AAMI TIR57, Principles for medical device security — Risk management; ANSI/AAMI SW96 on the interface between security and safety risk management; ISO/IEC 29147 and ISO/IEC 30111 on vulnerability disclosure and handling.