Cybersecurity is a hot topic. For medical device manufacturers, it is also a required topic by regulation (e.g., in the U.S., section 524B of the FD&C act).

However, that doesn’t mean that cybersecurity is “new.” There are lots of existing resources available to give you a jump-start in developing secure software.

Here is one approach to upping your security game:

1. Start with a compliant medical software process.
2. Find additional secure software coding frameworks and standards that you can adapt.
3. Leverage pending advanced AI cybersecurity capabilities.

Start with a compliant medical software process

A risk-based, full product lifecycle-driven approach that integrates effectiveness, quality, safety, and security is the target. While most of this post will address software and cybersecurity, do not assume that cybersecurity is the entirety of “security.” Medical device security should address broader concerns like physical theft and other factors depending on the device.

In the U.S. market, the FDA pre-market cybersecurity guidance specifically identifies a Secure Product Development Framework (SPDF) as one way to satisfy regulations regarding cybersecurity. A way to establish a good SPDF for software is by ensuring alignment with IEC 62304 (software lifecycle) and ISO 14971 (risk management) for basic compliance.

An alternative is to start with a general software framework like Microsoft Security Development Lifecycle (SDL) Practices (https://www.microsoft.com/en-us/securityengineering/sdl), then adapt the SDL with IEC 62304 and ISO 14971. Frameworks like SDL are adaptable to most organizations and may align well with other approaches like DevSecOps (devsecops.org).

Once you have a base compliant process, incorporate aspects as applicable from these key cybersecurity compliance references:

Find additional software coding frameworks and standards that you can adapt

There are established frameworks and checklists from trusted organizations like OWASP, CERT/SEI, and NIST. These focus on preventing common vulnerabilities (e.g., those in the OWASP Top 10 or CWE Top 25) through secure-by-design principles, rigorous validation, least privilege, and defense-in-depth. No single standard fits every project, but the most widely recommended and practical ones are technology-agnostic (OWASP) or language-specific (CERT). They can be integrated into your SPDF.

Examples:

OWASP secure coding practices quick reference guide

This is the gold standard for most teams. It is concise (easy to integrate into code reviews or CI/CD), technology-agnostic, and organized as a checklist focused on secure coding requirements rather than just vulnerabilities. It emphasizes server-side enforcement on trusted systems and failing securely.

Additional categories cover data protection, communication security (e.g., TLS everywhere), system/database/file configuration, and memory management. The full checklist is free and short– recommended as a starting point. https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/

CERT secure coding standards (language-specific)

Developed by Carnegie Mellon University’s Software Engineering Institute (SEI), these provide detailed, rule-based guidelines to avoid specific language vulnerabilities like buffer overflows, integer issues, and race conditions.

• Available for C, C++, Java, Android, and others.
• Rules are cross-referenced to CWE (Common Weakness Enumeration) and often mandatory in safety- and security-critical industries.
• Best for low-level languages; pair with OWASP for higher-level apps.

Download the latest editions from the SEI website (2016 editions are still foundational, with ongoing updates); C and C++ are at https://www.sei.cmu.edu/library/sei-cert-c-and-c-coding-standards/.

Design patterns

Secure architecture is a key pathway to building secure software. Examine GRASP (https://www.softwarecpr.com/2026/01/grasp-software-design/) and other existing design pattern for use to avoid recreating something already existing. Existing patterns still in use have often been vetted and updated for durability and security … though check to confirm. The same goes for algorithms (e.g., https://the-algorithms.com/).

Additional supporting frameworks and standards

How to implement these standards and frameworks effectively

• Embed in your SDLC — Treat security as non-functional requirements from the start (threat modeling in design, security code reviews, automated SAST/DAST/SCA in CI/CD).
• Adopt security by design — Follow least privilege, fail securely, centralize security logic, and use established libraries (never roll your own crypto).
• Train and enforce — Developer training on these checklists, automated linting/static analysis tools (e.g., SonarQube, Semgrep), and peer code reviews focused on security.
• Update regularly — Standards evolve; track new OWASP/CERT releases and emerging threats like supply-chain attacks.
• Measure success — Track metrics like vulnerability density, time-to-remediate, and coverage of secure coding rules.

Following these – especially starting with the OWASP checklist – can dramatically reduce the attack surface and helps you ship code that is secure by default.

Leverage pending advanced AI cybersecurity capabilities

Anthropic, and now OpenAI, have developed AI models that appear extremely sophisticated in analyzing and exploiting cybersecurity vulnerabilities. The models apparently go far beyond any current automated penetration testing capabilities.

An important step for manufacturers is to leverage these models when they become available. Use the models (or have a third party do so) to test both products in development and any existing products. You can be sure that it won’t be long until threat actors find a way to get the models and do the same.

Implementation Approach Summary

1. Adopt IEC 62304 as your SDLC → Map your processes to its clauses.
2. Build/align your QMS to QMSR and ISO 13485 → (Critical for US compliance by Feb 2026).
3. Perform risk management per ISO 14971 + SW96 → Include cybersecurity from day one.
4. Add IEC 81001-5-1 for security activities → (Especially if connected or SaMD).
5. Follow FDA guidances → For premarket submissions, labeling, and post-market surveillance.
6. Add non-medical frameworks and secure coding practices as applicable
7. Implement tools & practices: Automated traceability, SAST/DAST, SBOM generation, and penetration testing. See the prior post on importance of increasing speed in monitoring and response (https://www.softwarecpr.com/2026/03/ai-is-changing-cybersecurity-and-increasing-danger/) and SoftwareCPR’s May 2026 newsletter (excerpted post here https://www.softwarecpr.com/2026/05/ai-cyberattack-coming/). Tools are often a big help in increasing speed.

Additional Considerations

• AI/ML-enabled medical device software: Layer on FDA’s AI/ML guidance (e.g., lifecycle management, change control plans).
• SaMD vs. SiMD: IEC 62304 applies to both; IEC 82304-1 adds extra requirements for standalone health software like SaMD.
• Markets: Use these steps for FDA, CE marking, and MDSAP audits. Add other market-specific resources as needed for your product.

Finally, just because a resource is “old” doesn’t mean it isn’t useful. Older books like Donald Knuth’s The Art of Computer Programming series and Steve McConnell’s Code Complete are still helpful in learning both art and science of building successful software.

Have any favorite “go to” resources for secure software or medical devices overall? Let us know, and we’ll update the post!