Security Requirements and Controls
1.0 Purpose
This document provides developers and engineers of medical devices with guidance regarding System Security Requirements, Product Security Requirements and Design Specifications, and Security Controls. These are traced to one another in the table provided in Section of this document. Security control categories from the FDA’s 2025 Premarket Cybersecurity Guidance, Appendix 1. Security Control Categories and Associated Recommendations are also traced to these requirements and controls in the same table and appendix.
2.0 Security Principles
There are specific security principles that must be designed into the medical device system if it is to be a secure system:
Confidentiality – protecting information from unauthorized exposure
Integrity – protecting data or operations from unexpected or unauthorized modification
Availability – ensuring system resources, data, and effective operations are available when needed
Authenticity – ensuring all users, devices/endpoints, and information are trustworthy, valid, and accurate
Authorization – limiting users’ and devices’ permissions, functionality, and services to the minimum levels necessary for their intended role or operation
Non-Repudiation – ensuring accountability of user and device actions and events, and protecting this information from modification (ensuring forensic evidence capture)
3.0 Security Goals
Security Goals are derived from the above six Security Principles. These goals use “will-based language” to begin planning how the Security Principles will be designed into the system. Security Goals for a medical device system should be captured in the Security Risk Management Plan for the project, per FDA and other regulatory requirements. An example of a Security Goal is as follows: “All critical operations will be authenticated and authorized prior to being performed.”
4.0 System Security Requirements
The System Security Requirements are derived directly from the system’s Security Goals. Replacing “will” with “shall” in the same statements provides the Security Requirements at the system level. An example of a System Security Requirement is as follows: “All critical operations shall be authenticated and authorized before being performed.” This System Security Requirement stems from the Security Goal used in the example above in Section 3.0.
5.0 Software Requirement Specifications
Security Software Requirement Specifications, or Product Security Requirements, are derived from the System Security Requirements. Product Security Requirements should be more detailed than System Security Requirements and should be more specific to a user, a user interaction with a subsystem, a subsystem, or an interaction between subsystems; however, Product Security Requirements should not contain implementation details and should be implementation agnostic. An example of a Product Security Requirement is as follows: “The software shall uniquely authenticate all users at the beginning of a session.” This Product Security Requirement stems from the System Security Requirement used in the example above in Section 4.0.
6.0 Security Controls
Security Controls are derived from Product Security Requirements. Security Controls contain the implementation details that satisfy the Security Requirements in the system. Examples of Security Control information for the above Product Security Requirement example are as follows: “User authentication via username and password according to a policy. Users establish their own credentials on first login. Admin users require MFA. Passwords and MFA can be revoked, renewed, and otherwise managed by manufacturer.” These and additional examples of Security Control information are provided in Column 4 of the table in Appendix A (Section 9.0 of this document). The FDA’s 2025 Premarket Cybersecurity Guidance, Appendix 1. Security Control Categories and Associated Recommendations also provides helpful considerations when designing and documenting Security Controls and Requirements.
7.0 Mapping Requirements and Controls to FDA Control Categories
The FDA’s eight cybersecurity control categories organize security controls into logical groups. Each category aligns to one or more security principles and requirements. When performing design-time risk management (SEC-GUIDE-10), vulnerabilities are identified and linked to system or software requirements. The FDA provides the following categories for cybersecurity controls:
Authentication
Authorization
Cryptography
Code, Data, and Execution Integrity
Confidentiality
Event Detection and Logging
Resiliency and Recovery
Software and Firmware Updates
These categories serve as a structured taxonomy for documenting and demonstrating that the device’s controls address identified vulnerabilities comprehensively.
7.1 Authentication Controls
Authentication verifies the identity of users, devices, or systems before allowing interaction. It ensures that only trusted parties can access or control device functions and that unauthorized access attempts are managed appropriately. Example: A clinician logging into a programmer must provide valid credentials before sending configuration data to an implantable device. Mutual authentication may be used between the device and the hospital network to ensure both sides are trusted.
Helpful Tips:
Choose authentication methods proportionate to risk.
Define all user and system identities early in design.
Eliminate shared or hard-coded credentials and implement rotation processes.
Test how the system behaves during failed authentication attempts.
7.2 Authorization Controls
Authorization ensures that authenticated users, systems, and processes only have the privileges they need to perform intended actions. Example: A hospital technician may configure network settings but cannot modify therapy algorithms.
Helpful Tips:
Apply the principle of least privilege for all roles.
Use RBAC or ABAC access models.
Review roles and permissions periodically to prevent privilege creep.
Link authorization with logging for accountability.
7.3 Cryptography Controls
Cryptography protects confidentiality, integrity, and authenticity of data and communications. It provides the technical backbone for device trust. Example: An implant encrypts logs and uses TLS 1.3 for communications. Firmware updates are digitally signed and verified.
Helpful Tips:
Use approved, standards-based algorithms and validated modules.
Reference the Velentium Medical Cryptographic Assurance Levels (VEL-CAL) Framework (SEC-GUIDE-09) to select appropriate cryptographic strength.
Implement proper key management for generation, storage, and rotation.
Prepare for post-quantum cryptography where applicable.
7.4 Code, Data, and Execution Integrity Controls
Integrity controls ensure code, data, and execution remain trustworthy and unaltered. Example: A secure bootloader verifies firmware at startup and detects unauthorized modification.
Helpful Tips:
Implement secure boot and firmware signing.
Include runtime integrity checks and safe failure modes.
Use checksums or MACs to verify data.
Log and handle detected integrity failures safely.
7.5 Confidentiality Controls
Confidentiality controls protect sensitive data from unauthorized exposure or disclosure. Example: Personal health information is encrypted at rest and in motion, with strict access management.
Helpful Tips:
Encrypt sensitive data wherever possible.
Secure debug and maintenance interfaces.
Define retention and disposal procedures.
Limit collected data to what is necessary.
7.6 Event Detection and Logging Controls
Event detection and logging create traceability for system activity and security events. Example: A device logs failed authentication attempts and update operations with timestamps and protection against tampering.
Helpful Tips:
Define which events must be logged.
Protect logs from deletion or alteration.
Review logs regularly or via automation.
Maintain retention policies aligned with postmarket surveillance (SEC-GUIDE-07).
7.7 Resiliency and Recovery Controls
Resiliency ensures safety-critical functions remain active during disruptions. Recovery restores normal operation securely after faults or attacks. Example: A device continues therapy during communication loss and restores full capability when connectivity returns.
Helpful Tips:
Identify essential safety functions.
Design fallback or safe-state modes.
Test recovery processes regularly.
Document recovery metrics in testing reports.
7.8 Software and Firmware Update Controls
Software and firmware update controls ensure secure and traceable updates throughout the device’s life. Example: A connected device downloads a signed update, verifies its authenticity, and prevents rollback to older, insecure versions.
Helpful Tips:
Digitally sign and verify updates and use encrypted update channels.
Implement rollback prevention.
Define clear communication for updates and EOS.
8.0 Next Steps
Velentium Medical can help you implement cybersecurity governance within your organization, develop secure products, generate submission-ready artifacts, maintain and sustain medical devices during postmarket, and train your personnel, all based on the latest, state of the art standards and best practices for medical device cybersecurity. We can offer templates and be your guides, we can be your outsourced testing partner, or we can do everything for you with in-house experts and engineers. Contact us and learn more at www.VelentiuMedical.com/Cybersecurity.
