Issue: September 6, 2026

This week’s briefing covers developments on post-quantum cryptography (PQC), new draft documents from NIST and a paper published by H-ISAC. The G7 Cybersecurity Working Group and CISA issued a joint call to action urging organizations to begin PQC migration now, singling out firmware signing, secure boot, and update authentication as the mechanisms most exposed once quantum computers arrive, while Health-ISAC published a white paper (co-authored by product security leaders at ten large device manufacturers) proposing a standard set of cybersecurity metrics for procurement and board reporting. NIST opened two comment periods relevant to devices: an initial public draft of SP 800-38E Rev. 1 tightening the approved-use conditions for XTS-AES data-at-rest encryption (comments due 16 October), and a pre-draft call to revise the SP 800-213A IoT requirement catalog toward a product-level rather than device-level scope (comments due 15 October). On deadlines, the EU CRA’s vulnerability and incident reporting obligations begin 11 September via ENISA’s Single Reporting Platform, while the proposed slip of the CRA horizontal harmonised-standard drafts to 31 October remains unconfirmed in the Official Journal.

1. G7 Cybersecurity Working Group and CISA Issue Joint Call to Action on Post-Quantum Cryptography Migration

On 3 September 2026, France’s ANSSI, which chairs the G7 Cybersecurity Working Group under France’s 2026 G7 Presidency, published “Preparing for the Post-Quantum Era: A Call to Action” jointly with the other six members of the group (Canada’s CSE, Germany’s BSI, Italy’s ACN, Japan’s National Cybersecurity Office, the UK’s NCSC, and the U.S. CISA), with participation from the European Commission and ENISA. The statement urges governments and organizations to begin transitioning to post-quantum cryptography (PQC) immediately, rather than waiting for cryptographically relevant quantum computers (CRQCs) to materialize.

What the call to action says

The document warns that malicious actors are already conducting “harvest now, decrypt later” attacks (intercepting and storing today’s public-key-encrypted traffic for future decryption once a CRQC becomes available), meaning organizations handling data that must stay confidential for years (health records among them) are exposed now, not just at some future date. It also flags a second, less-discussed risk: once available, CRQCs could let attackers forge authentication mechanisms, impersonate trusted entities, or compromise device and firmware integrity, which is the pathway most directly relevant to connected products. The G7 group lays out five priorities (raising awareness, building national PQC strategies, funding quantum-safe R&D, fostering public-private partnerships, and integrating PQC requirements into procurement) and recommends a phased, risk-based approach starting with a cryptographic asset inventory, dependency mapping, and a migration plan, timed to normal technology refresh cycles to limit cost.

Manufacturer relevance

Medical devices routinely store and transmit personal/patient information (PII), which puts them squarely in the path of the harvest-now-decrypt-later risk. Any PII a device sends over the network (sessions to back-end servers, gateways, and cloud services; remote-monitoring and telemetry feeds; VPN tunnels) or holds at rest (on-device storage, local backups, cloud archives) is in practice protected by a classical public-key step: an RSA or ECDH key exchange for the transmitted data, or an RSA/ECC key wrapping the symmetric key for the stored data. The bulk cipher itself (AES) is not the weak point; the public-key key establishment and key wrapping around it are, and an adversary who captures that ciphertext today can read it once a CRQC exists. Because health data has a confidentiality lifetime measured in decades, that exposure is present-day, not hypothetical. The statement’s second risk, a CRQC being used to forge authentication or compromise device and firmware integrity, is the one that maps to firmware signing, secure boot, and update authentication, and it is a future rather than an immediate concern. FDA’s premarket expectations already call for security risk management across the total product lifecycle, so a cryptographic inventory is a low-cost extension of existing SBOM and threat-modeling work: manufacturers should catalog where public-key cryptography protects patient data in transit and at rest, treat crypto-agility (swapping key-establishment and signature algorithms without a redesign) as a design requirement for new platforms, and move new device communications toward post-quantum or hybrid key establishment such as the NIST-standardized ML-KEM, so a migration plan is ready before a regulator or customer asks for one.

Sources: Preparing for the Post-Quantum Era: A Call to Action - G7 Cybersecurity Working Group / ANSSI, September 2026 (full text: PDF); Preparing for the Post-Quantum Era: A Call to Action - CISA, 3 September 2026

2. Health-ISAC White Paper, Co-Authored by Major Device Manufacturers, Proposes a Standard Set of Cybersecurity Metrics for Procurement and Board Reporting

On 1 September 2026, Health-ISAC published “From Metrics to Meaning: Transforming Medical Device Cybersecurity into a Strategic Risk Narrative,” a white paper written collaboratively by product security leaders from ten organizations (including Medtronic, Abbott, Stryker, Boston Scientific, BD, Baxter, Fresenius, B. Braun, and Amgen), alongside Health-ISAC itself.

What the paper recommends

The paper’s diagnosis is that manufacturers already generate abundant cybersecurity data (SBOMs, vulnerability scans, quality-system records, regulatory filings) but that data sits in disconnected systems and rarely gets translated into a narrative regulators, boards, or hospital customers can act on. It proposes organizing metrics into four pillars (vulnerability management and operations, compliance/audit/risk, lifecycle and asset management, and strategic maturity and investment) and recommends prioritizing remediation by exploitability (Known Exploited Vulnerabilities) rather than raw CVE count. It also proposes a two-layer reporting model: operational metrics that show whether the team is executing (defect density, time-to-patch-readiness, field deployment coverage at 25/50/75/90%) feeding into executive metrics that show whether the organization is actually getting safer (inspection-finding risk, field-corrective-action exposure, structural risk from unsupported end-of-life components). The paper flags field deployment coverage as the figure most often missing from vendor patch communications even though it determines whether a fix reached the installed base.

Manufacturer relevance

Because the paper was written by product security leaders at large manufacturers rather than by a hospital association or vendor, it carries unusual weight as a de facto industry benchmark: a health system procurement team can now ask a vendor for the same five figures (defect density, time-to-patch-readiness, deployment coverage, open KEVs beyond tolerance, and count of shipped products with unsupported third-party components) that the manufacturer’s own peer group endorsed. The Health Sector Coordinating Council’s model contract language (v2, November 2025) already gives hospitals enforceable provisions on patch commitments and disclosure timelines; this paper gives those provisions concrete metrics to measure against. Manufacturers should expect these or similar figures to start appearing in RFPs and renewal negotiations, and should assess now whether their existing SBOM, vulnerability-management, and QMS tooling can actually produce field deployment coverage data. The paper’s own admission is that many manufacturers currently cannot.

Sources: From Metrics to Meaning: Transforming Medical Device Cybersecurity into a Strategic Risk Narrative - Health-ISAC, 1 September 2026; Medical Device Cybersecurity Needs Better Story to Tell, Report Urges - SecureWorld, 2 September 2026

3. NIST Releases Draft Revision of SP 800-38E (XTS-AES Storage Encryption) for Public Comment

On 3 September 2026, NIST released the initial public draft of Special Publication (SP) 800-38E Revision 1, Recommendation for Block Cipher Modes of Operation: XTS-AES Mode for Confidentiality on Storage Devices. SP 800-38E is the NIST recommendation that approves the XTS-AES mode of operation for protecting the confidentiality of data at rest on storage devices; this is its first revision since the original 2010 publication. The public comment period runs through 16 October 2026.

What the draft changes

Rather than reproducing the XTS-AES specification, the recommendation incorporates the IEEE 1619 standard by reference, and Revision 1 updates that reference from IEEE Std. 1619-2007 to IEEE Std. 1619-2025. Beyond the version bump, the draft clarifies NIST’s requirements for the approved use of XTS-AES in four areas: its scope of use (XTS-AES is approved specifically for encryption of data at rest on storage devices, not for data in transit or general-purpose confidentiality), data-unit and key-scope limits, key requirements, and the ordering convention for ciphertext stealing. To support review, NIST and IEEE have made IEEE Std. 1619-2025 publicly available for the duration of the comment period.

Manufacturer relevance

XTS-AES is the mode most commonly used for full-disk and full-media encryption, so it is the primitive underneath data-at-rest protection on a wide range of devices with local storage: imaging workstations, point-of-care analyzers, infusion and monitoring platforms that cache PHI locally, and any device whose threat model treats physical theft or drive removal as an attack path. FDA premarket cybersecurity expectations call for a documented approach to protecting the confidentiality of data at rest where the device stores sensitive information, and pointing to a NIST-approved mode is a common way to substantiate that control. Manufacturers relying on XTS-AES (directly or through an OS or self-encrypting-drive feature) should note that the approved-use conditions (data-unit size limits, key-scope limits, and the constraint that XTS-AES is not approved outside the storage-device context) are being tightened and made explicit; existing designs should be checked against the clarified limits before the final revision publishes, and teams with comments on the data-unit or key-scope constraints have until 16 October 2026 to submit them.

Sources: SP 800-38E Rev. 1 (Initial Public Draft): Recommendation for Block Cipher Modes of Operation: XTS-AES Mode for Confidentiality on Storage Devices - NIST CSRC, 3 September 2026

4. NIST Opens Pre-Draft Call for Comments on Revision of the IoT Device Cybersecurity Requirement Catalog (SP 800-213A)

On 31 August 2026, NIST posted a Pre-Draft Call for Comments to begin a revision of Special Publication (SP) 800-213A, IoT Device Cybersecurity Guidance for the Federal Government: IoT Device Cybersecurity Requirement Catalog. SP 800-213A is the companion catalog to SP 800-213: it enumerates the specific technical and non-technical cybersecurity capabilities a federal agency can require of an IoT device, organized so agencies can select and tailor them to a system. The call for comments follows the June 2026 draft update to the parent document, SP 800-213 Revision 1, which itself reframes the guidance around IoT products rather than individual devices. Comments are due by 15 October 2026, submitted to iotsecurity@nist.gov with the subject line “Comments on SP 800-213A.”

What the revision is expected to address

NIST states the update aims to incorporate lessons learned since the 2021 publication, align the catalog with newer frameworks, namely the Cybersecurity Framework (CSF) 2.0 and SP 800-53 Rev. 5.2.0, and reflect an evolved IoT threat landscape. The pre-draft questions specifically seek input on expanding scope from IoT devices to IoT products (device plus its supporting software, apps, and cloud/back-end components), emerging IoT use cases, tailored deployments of individual capability components, and additional source guidelines that should feed the catalog.

Manufacturer relevance

SP 800-213A is a federal-procurement instrument, not a medical device regulation, but it is influential well beyond its formal scope: the catalog’s capability structure is a common reference for defining “what good looks like” in a device cybersecurity requirements set, and hospital and integrated-delivery-network procurement teams borrow from it. The shift from device-level to product-level scope mirrors the direction of FDA premarket expectations, the EU CRA, and the Health-ISAC metrics work in Section 2: regulators and buyers increasingly want assurances about the whole product system (companion apps, update infrastructure, cloud services), not just the device on the bench. Manufacturers that sell to U.S. federal customers (VA, DoD, IHS) should track the revision directly, since it will shape future contract language; others can use the pre-draft questions as a preview of where baseline capability expectations are heading. Product security teams with a view on the device-versus-product scope question have until 15 October 2026 to comment.

Sources: Call for Comments on NIST SP 800-213A - NIST CSRC, 31 August 2026; SP 800-213 Rev. 1 (Initial Public Draft): IoT Product Cybersecurity Guidelines for the Federal Government - NIST CSRC, June 2026