FDA Changed the Rules in 2023. Is Your Medical Device Ready?

For decades, cybersecurity in medical devices was often treated as a software problem. It was something to be considered towards the end of development, addressed through penetration testing before submission, or added as another section in regulatory documentation.

That approach is no longer sufficient.

In 2023, medical device cybersecurity entered a new regulatory era. New statutory requirements took effect under section 524B of the Federal Food, Drug, and Cosmetic Act, and the U.S. Food and Drug Administration (FDA) released substantially updated guidance explaining its expectations for secure device development.

Those expectations have continued to evolve. The FDA updated its guidance again in 2025 and 2026, reinforcing the same underlying message: cybersecurity must be treated as a lifecycle engineering responsibility, not a final-stage submission activity.

For manufacturers developing connected medical devices, software as a medical device (SaMD), cloud-connected platforms or even traditional embedded systems, the implications are significant. Organisations that continue treating cybersecurity as a late-stage compliance activity may face increased regulatory scrutiny, costly redesigns and delayed submissions.

The manufacturers that will succeed are those who build cybersecurity into the engineering process from the very beginning.

More Than a Regulatory Update

It’s easy to think of the FDA’s 2023 guidance as simply another document to comply with.

In reality, it represents a shift in philosophy.

Rather than asking, “Does your product include cybersecurity features?”, the FDA is increasingly asking: “Can you demonstrate that cybersecurity has been systematically considered throughout the entire product lifecycle?”

That means cybersecurity is now expected to influence product architecture, software development, risk management, verification, documentation and post-market maintenance, not just the software code itself.

The comparison below illustrates how dramatically expectations have evolved.

Before 2023	Today
Cybersecurity often addressed near regulatory submission	Cybersecurity integrated throughout product development
Focus on individual security features	Focus on a Secure Product Development Framework (SPDF)
Limited cybersecurity documentation	Comprehensive lifecycle evidence expected
Security testing performed late in development	Security activities planned from concept through post-market support
Compliance-driven mindset	Engineering-driven, risk-based approach

This shift reflects the reality that modern medical devices are increasingly connected.

Devices now communicate with hospital networks, cloud services, mobile applications and third-party systems, creating a much larger attack surface than ever before.

Cybersecurity is no longer simply an IT concern. It has become a patient safety issue.

What the FDA Now Expects

One of the biggest misconceptions surrounding the updated guidance is that manufacturers simply need to provide more documentation.

Documentation is certainly important, but documentation alone isn’t enough.

The FDA expects manufacturers to demonstrate that cybersecurity has been incorporated into the design and development process itself.

Depending on the device and submission pathway, this typically includes evidence of activities such as:

• A Secure Product Development Framework (SPDF)

• Cybersecurity risk management connected with ISO 14971 safety risk management

• Threat modelling and attack surface analysis

• Security architecture documentation

• Software Bill of Materials (SBOM) and third-party software management

• Security requirements and traceability

• Verification of implemented security controls

• Vulnerability assessment and penetration testing

• Software update and patch management strategies

• Post-market vulnerability monitoring

• Coordinated vulnerability disclosure processes

• Cybersecurity management and maintenance planning

For certain internet-connected medical devices, some of these activities—including vulnerability-management planning, software updates and an SBOM—are now statutory submission requirements, not simply recommended practices.

Notice that very few of these activities happen at the end of a project. Most need to begin during product definition and continue throughout development.

The Secure Product Development Framework (SPDF)

Perhaps one of the most significant concepts emphasised by the FDA is the Secure Product Development Framework (SPDF).

Rather than viewing cybersecurity as a series of isolated activities, an SPDF embeds security into every stage of the development lifecycle.

That includes:

• defining security requirements alongside functional requirements

• identifying threats before implementation begins

• integrating cybersecurity into risk management

• designing secure system architectures

• verifying security controls during development

• planning for software updates and vulnerability management after product release

  
  

For engineering teams, this changes the conversation completely.

Instead of asking “How do we secure this product before submission?”, the better question becomes: “How do we engineer this product securely from day one?”

This approach not only improves regulatory readiness but also reduces expensive redesigns later in the project.

The Biggest Challenge Isn’t Usually Security

One of the most common issues seen across the industry isn’t necessarily insecure products.

It’s missing evidence.

Many organisations already implement authentication, encryption, access control and secure communication protocols. However, when preparing for an FDA submission, they discover that the engineering rationale behind those decisions was never documented.

Questions begin to emerge.

• Why was this security control selected?

• What threats does it mitigate?

• How was it verified?

• How does it integrate with the overall risk management process?

• What happens if a vulnerability is discovered after release?

  
  

Answering these questions retrospectively can require significant engineering effort and often delays submissions.

Building cybersecurity into the development process from the outset is considerably more efficient than reconstructing evidence months or even years later.

Engineering Activities That Matter

While every device is different, robust medical device cybersecurity programs typically include several core engineering activities.

Threat Modelling

Threat modelling identifies how a product could realistically be attacked before vulnerabilities become expensive design changes.

Methodologies such as STRIDE allow engineering teams to systematically evaluate spoofing, tampering, repudiation, information disclosure, denial of service and privilege escalation, linking each identified threat to mitigation strategies and verification activities.

Cybersecurity Risk Management

Cybersecurity risk management should work alongside a manufacturer’s existing ISO 14971 safety risk management process.

The two disciplines assess risk differently, but they need to remain connected. A cybersecurity vulnerability may create or contribute to a patient safety hazard, while a security control may affect the device’s safety, usability or clinical performance.

Connecting the two processes creates stronger traceability between security threats, patient harms, risk controls and verification evidence, without creating an entirely disconnected documentation system.

Security Architecture

Security architecture documentation has become increasingly important.

Manufacturers are expected to demonstrate how trust boundaries, communication pathways, authentication mechanisms, update processes and security controls fit together across the entire system, not just within individual software modules.

Verification

Security controls must also be verified.

This may include authentication testing, access control verification, encryption validation, vulnerability assessments and penetration testing to demonstrate that implemented controls perform as intended.

Cybersecurity Is More Than Penetration Testing

Penetration testing is important, but it represents only one part of a secure development process.

A robust cybersecurity program also considers:

• how users, systems and software components are authenticated and authorised

• how sensitive data and critical software are protected from unauthorised access or modification

• how third-party and open-source software vulnerabilities are identified and managed

• how security events are detected, recorded and investigated

• how the device can recover from a cybersecurity incident

• how software updates can be delivered securely

• how security will be maintained when components reach the end of support

  
  

The appropriate controls will vary between products. What matters is that they are selected deliberately, linked to identified risks and verified as part of the engineering process.

Cybersecurity Doesn’t End at Product Release

Historically, regulatory submissions often marked the end of cybersecurity activities.

Today, they mark the beginning of an ongoing responsibility.

The FDA increasingly expects manufacturers to monitor vulnerabilities, evaluate emerging threats, manage software updates and maintain documented post-market cybersecurity processes throughout the product’s operational life.

In practice, this requires clear ownership for vulnerability monitoring, defined sources of security intelligence, periodic testing, processes for assessing newly discovered vulnerabilities, realistic patch-release timelines and a plan for communicating updates to customers. Manufacturers must also consider what happens when the device or one of its critical software components reaches the end of support.

For products expected to remain in service for ten years or more, this long-term perspective is essential.

A secure device isn’t simply one that launches securely. It’s one that remains secure as threats, technologies and regulatory expectations evolve.

How Genesys Supports Medical Device Manufacturers

At Genesys, cybersecurity isn’t treated as a standalone consulting service. It is integrated into the broader engineering and product development process.

Our team has supported multiple medical device manufacturers in preparing products for modern cybersecurity expectations, including projects involving Electrogenics’ MOSkin Radiation Dosimetry System, Navbit’s surgical planning platform and Universal Biosensors.

Our experience includes:

• FDA eSTAR cybersecurity readiness assessments

• Secure Product Development Framework implementation

• STRIDE threat modelling

• Cybersecurity Management Plans

• Cybersecurity Reports

• Security architecture reviews

• Connecting cybersecurity risk management with ISO 14971 safety risk management

• Verification planning and penetration testing preparation

• Product Maintenance Plans

• Vulnerability monitoring and post-market cybersecurity planning

  
  

Rather than simply interpreting guidance documents, we work alongside engineering teams to integrate cybersecurity into the product lifecycle, helping manufacturers produce stronger evidence, reduce regulatory risk and build more resilient products.

Looking Ahead

Medical devices will continue becoming more connected, more software-driven and more dependent on cloud infrastructure, artificial intelligence and remote services.

As connectivity increases, cybersecurity will only become more important.

The organisations that treat cybersecurity as an engineering discipline, not just a compliance requirement, will be better positioned to navigate future regulations, accelerate regulatory submissions and deliver safer, more resilient products.

The changes that began in 2023 weren’t simply another regulatory update. They signalled a new expectation for how medical devices should be engineered.

The question is whether manufacturers’ development processes are ready for the future.