Issue: August 16, 2026

1. IMDRF Finalizes Global Framework for Predetermined Change Control Plans, With Direct Implications for Security-Patch Deployment

On 6 August 2026, the International Medical Device Regulators Forum (IMDRF) published a finalized technical document — IMDRF/SaMD WG/N90, developed by its Software as a Medical Device Working Group — setting out the essential principles regulators should apply when adopting Predetermined Change Control Plans (PCCPs). The document follows a 60-day public consultation on the draft version that ran October–December 2025 and drew 143 comments from 10 stakeholders.

What the document covers

A PCCP allows a manufacturer to make certain pre-authorized changes to a marketed device’s software without filing a new submission or supplement, provided those changes were specified and agreed with the regulator in advance. IMDRF’s finalized document lists five essential principles for regulators to apply — limiting changes to the software’s intended use, a risk-based approach, an evidence-based approach with ongoing evaluation, transparency, and a total-product-lifecycle approach — and three required elements of a PCCP itself: a description of planned changes, a verification-and-validation change plan, and an impact assessment. The document is scoped specifically to medical device software; IMDRF noted PCCPs “have the potential to be applied beyond medical device software to other areas of medical technology” in the future, but “the focus of this document is on medical device software.” It also stresses that PCCPs must operate within a manufacturer’s existing quality management system and risk-management process, with careful version control so regulators and manufacturers can track which authorized software version is in the field. IMDRF further cautioned that revisions to an already-authorized PCCP will generally require reauthorization, since they modify something that would otherwise require a new submission — though some jurisdictions may permit minor PCCP changes without it.

Manufacturer relevance

The US FDA has accepted PCCPs since before their explicit 2022 statutory authorization under FDORA, but most other regulators are still building their own frameworks; this document gives them a harmonized international template to work from, which should reduce the odds of conflicting PCCP requirements across jurisdictions over time. For manufacturers, PCCPs are a direct lever for cybersecurity patch management: routine, pre-specified security updates that fit within an authorized PCCP’s parameters can be deployed without triggering a new regulatory submission, provided the change plan and impact assessment were built to anticipate them. Manufacturers developing or expanding PCCPs — particularly for connected or software-driven devices — should ensure security-patch scenarios are explicitly contemplated in the description of changes and impact assessment, and should track how individual regulators (FDA, and now others aligning with this IMDRF document) diverge on reauthorization thresholds for PCCP revisions.

Sources: IMDRF details key principles for regulators to adopt PCCPs - Regulatory Focus (RAPS), 10 August 2026; IMDRF/SaMD WG/N90: Essential Principles and Content for Predetermined Change Control Plans - IMDRF, 6 August 2026

2. Dutch Cybersecurity Act Enters Into Force — First Major National NIS2 Deadline of This Cycle

The Netherlands’ Cyberbeveiligingswet (Cybersecurity Act, “Cbw”), which transposes the EU’s NIS2 Directive into Dutch law, entered into force on 15 August 2026 alongside the related Wet weerbaarheid kritieke entiteiten (Critical Entities Resilience Act, “Wwke”). The Dutch Senate adopted the law on 7 July 2026, closing out one of the EU’s longest-outstanding NIS2 transposition gaps.

What changed this week

From 15 August, the Dutch NIS2 regime applies in full to roughly 8,000 in-scope entities, including a registration obligation, a duty of care, incident-reporting obligations, and board-level governance requirements. Dutch law does not include a general grace or transition period comparable to phased approaches taken in some other member states (higher-education institutions are the one exception, with a three-year transition), so obligations bind immediately for entities already in scope. Penalties can reach €10 million or 2% of global annual turnover (whichever is higher) for essential entities, and €7 million or 1.4% of turnover for important entities. The Netherlands was among the member states the European Commission referred to the Court of Justice of the EU on 8 July 2026, alongside Ireland, Spain, and France, for missing NIS2’s original October 2024 transposition deadline; the Dutch law’s entry into force this week resolves that gap for the Netherlands specifically, while the other three referred states remain outstanding — Ireland has said it expects to notify transposition by the end of 2026, while France and Spain currently have no firm completion date.

Manufacturer relevance

Medical device manufacturers with Dutch manufacturing sites, EU distribution operations, or other Dutch-registered entities that fall within NIS2’s scope as important or essential entities in the health sector must now meet Dutch registration and incident-reporting timelines with no phase-in cushion. Manufacturers who have been tracking NIS2 at the EU level but have not separately confirmed their Dutch-entity registration status should do so now; unlike the CRA’s phased reporting rollout, this obligation is already live as of this week for covered Dutch entities.

Sources: Dutch Cybersecurity Act enters into force on 15 August 2026: what organisations should do now - Clyde & Co; NIS2 Alert: Dutch Cybersecurity Act (Cyberbeveiligingswet) has been adopted - Bird & Bird; Cbw and Wwke enter into force today - Dutch Digital Government; EU takes member states to court over unimplemented cybersecurity law - The Record

3. CISA Flags Unauthenticated Bluetooth Command Flaws in Two Home Neurostimulation Devices, With Divergent Vendor Responses

CISA published two ICS Medical Advisories in the same week for battery-powered, Bluetooth-connected neurostimulation devices sold directly to consumers: a vagus nerve stimulator (ICSMA-26-223-02, published 11 August 2026) and a transcranial stimulator (ICSMA-26-225-01, published 13–14 August 2026, also carried by Spain’s INCIBE-CERT as INCIBE-2026-557).

What the advisories found

In the first device, tracked as CVE-2026-18844 (CVSS v3.1: 8.1/High, CWE-912 “hidden functionality”), the firmware accepts several undisclosed commands over its Bluetooth Low Energy interface that are never issued by the companion app, are sent without authentication or encryption, and are fully processed whenever the device is powered on — CISA and the researcher who reported it warn this could let a nearby attacker disable the device’s electrical safety mechanisms or alter stimulation output. CISA noted that the manufacturer has not responded to its outreach to coordinate a fix. In the second device, tracked as CVE-2026-18164 (rated “High” severity), an undocumented, hardcoded credential shared across every unit in the field allows authentication to be bypassed by anyone within Bluetooth range, enabling arbitrary manipulation of stimulation parameters and state; unlike the first device’s manufacturer, this manufacturer has engaged and shipped a firmware update through its companion app that closes the unauthorized-access path. Neither vulnerability has known active exploitation.

Manufacturer relevance

Both advisories land on the same underlying design failure — proximity-based wireless interfaces with no authentication layer on safety-relevant commands — in a fast-growing category of low-classification, direct-to-consumer neurostimulation products that may receive less premarket cybersecurity scrutiny than traditional prescription devices. The contrast in vendor response is itself instructive: the second manufacturer’s prompt engagement with CISA and firmware fix limited the disclosure to a standard advisory, while the first manufacturer’s non-response leaves users without an official mitigation and elevates both patient-safety and reputational exposure. Manufacturers of any BLE- or wireless-connected device — regardless of FDA classification — should treat command-level authentication and encryption on safety-critical functions as a baseline design requirement, and should have a coordinated-disclosure process in place and staffed before CISA or another CERT makes first contact.

Sources: ICSMA-26-223-02 - CISA, 11 August 2026; CVE-2026-18844 - CVE.org; ICSMA-26-225-01 - CISA, 13 August 2026; INCIBE-2026-557 - INCIBE-CERT, 14 August 2026