Software, SaMD and cybersecurity

The situation

The device is software, or has software that matters. Someone has asked whether it is a medical device at all; a notified body or the FDA has asked for the cybersecurity documentation; the roadmap includes model retraining and nobody knows what that does to the authorisation; and a European customer has asked about the AI Act. These questions arrive separately and are answered separately, by different people, in documents that do not agree.

What goes wrong when this is handled late

Software files fail in characteristic ways. The IEC 62304 safety class is chosen to minimise documentation rather than from the hazard analysis, and the reviewer notices that the risk file and the software plan disagree. The cybersecurity section is written last, from a template, without a threat model, and cannot answer the first question about a specific attack path. The usability file describes a formative study that never happened. The AI model is described as "locked" in the submission and retrained the following quarter. The EU AI Act is treated as either irrelevant or terrifying, when it is neither.

What Authentcare does

Assess. Qualify and classify the software in each market. Set the IEC 62304 safety class from the hazard analysis. Inventory the documentation the device regulation, the cybersecurity expectations and the AI requirements each demand, and find the overlaps. Assess whether the planned modifications are PCCP candidates. Determine whether and when the AI Act applies.

Develop. Write the integrated plan: one document inventory, one sequence, one owner per document. Build the IEC 62304 records, the usability engineering file, and the cybersecurity set from a single threat model that serves both FDA and MDCG 2019-16. Draft the PCCP's description of modifications, modification protocol and impact assessment where one is proposed. Write the AI Act gap analysis against the Article 6(1) obligations.

Coordinate. Brief the verification team and the penetration testers on what the file needs from them. Plan the formative and summative usability studies with the firm that runs them. Prepare the software and cybersecurity sections for the Q-Submission or the structured dialogue, and rehearse the questions.

AI-enabled devices

Three facts shape the strategy for an AI-enabled device in 2026. In the US, FDA's guidance on predetermined change control plans for AI-enabled device software functions is final, so a manufacturer can describe planned retraining and performance changes in the marketing submission and implement them without a new submission if they stay within the authorised plan; the broader lifecycle guidance remains draft, with finalisation on CDRH's FY2027 list. In the EU, the AI Act as amended by the Digital Omnibus on AI treats AI that is a device, or a safety component of one, requiring notified-body assessment as a high-risk AI system under Article 6(1), with obligations applying from 2 August 2028. And everywhere, the device regulation still comes first: the AI Act and the PCCP sit on top of a classified, risk-managed, verified device, not instead of one.

What you receive

• Software qualification and classification memo under MDCG 2019-11, FDA policy and IEC 62304 safety classification
• Integrated regulatory plan — document inventory and sequence across the device regulation, cybersecurity and AI requirements
• IEC 62304 lifecycle documentation — development plan, requirements, architecture, risk management, verification, release, maintenance and problem resolution
• Usability engineering file to IEC 62366-1 and current FDA human factors guidance (studies coordinated)
• Cybersecurity documentation — threat model, security risk management, SBOM, security architecture views, testing summary and post-market plan — for FDA section 524B and MDCG 2019-16
• AI-enabled device strategy, including Predetermined Change Control Plan assessment and drafting support under FDA's final PCCP guidance for AI-enabled device software functions
• EU AI Act applicability assessment and gap analysis for devices that are high-risk AI systems under Article 6(1)

Frameworks and editions

Applicability is device-specific. Which of these apply, and in what combination, depends on device type, intended purpose, classification and target market; the applicability assessment at the start of every engagement settles it in writing.

What this engagement excludes

• Software development, verification testing and penetration testing; the manufacturer or specialist firms perform them
• Summative usability studies; coordinated, not run
• Hosting, cloud security operations and incident response for the deployed product
• Notified-body and FDA fees