Safe and Secure in Embedded Software for MedTech: Standards, Practical Patterns, and Cross-Industry Lessons

• Long lifecycles with frequent updates: Maintain secure, safe updates over 10+ years while preserving compliance evidence.
• Heterogeneous platforms and SOUP: Mixed toolchains and third‑party code complicate consistent safety/security controls.
• Connectivity and interoperability: New attack surfaces and certification complexity (e.g., hospital IT and IEC 62443).
• Skills and tooling: High complexity in cryptography, secure update pipelines, and redundant architectures; tools must make correct-by-default easier.

• IEC 62304: Software lifecycle, classification, verification, maintenance, and problem resolution.
• ISO 14971: Risk management with clear hazard identification, risk controls, and residual risk.
• Supporting frameworks: IEC 60601-1 (basic safety/essential performance), IEC/TR 60601-4-5, which refers to IEC 62443 (security for IACS), and guidance on SBOM and coordinated disclosure.

Lock-Stepping

In lock-stepping, two identical CPU cores execute the same instructions in sync. A hardware comparator continuously checks the registers/results of both cores. As soon as a discrepancy is detected, an error is reported, and the system can transition to a safe state. This contributes to safety as follows:

• Error detection: 2oo2 (two-out-of-two) architecture to detect discrepancies.
• Shorter error reaction time: continuous comparison enables rapid fail-silent or fallback behavior.
• Support for the safety case: in combination with ECC-protected memory, a watchdog, clock/power monitoring, and end-to-end protection, it establishes a closed error-detection chain across computing cores, memory, and communication.

Trusted Execution Environment

Hardware-supported partitioning of the system into a “Secure/Trusted World” and a “Normal World”. The Secure World has isolated access to memory, peripherals, and cryptographic material; the Normal World is strictly separated from it.

• Protection of security-relevant artifacts: Security requirements, calibrations, configurations, safety state machines, and error counters can reside in the Secure World and are protected against unintended changes or manipulation.
• Freedom from interference: Hardware isolation (Secure vs. Normal) complements partitioning (MPU/MMU) and reduces the risk that faulty or non-secure software impacts safety-relevant areas.
• Key and communication protection: Secure key management and signature/CMAC for configurations, logs, and safety-critical messages increase the detection of data corruption and unauthorized changes.

Secure Updates

A secure update is a software update that is protected against tampering throughout its entire lifecycle, originates only from authorized sources, and can be applied without compromising security or functionality. The essential components are:

• Authenticity: Updates are digitally signed (code signing); only packages from trusted sources are accepted.
• Integrity: Hash checks ensure that contents remain unchanged.
• Authorization and access: Role-/rights management ensures that only authorized services/users can initiate updates.
• Confidentiality and secure transport: Download via secured channels (e.g. TLS/mTLS), protection against man-in-the-middle attacks.

Secure Communication

Protects against malicious or accidental attacks from outside or inside: confidentiality, integrity, authentication, replay protection.

• Strong crypto services with hardware assist.
• Transmitted messages are supplemented with authentication information (e.g. MAC) and freshness values.
• Use of encryption protocols such as TLS.

Safe Communication

Ensuring safe communication inside the control unit and between control units. This is made possible for external communication by:

• CRC over data, data ID and sequence counter. Allows to detect corruption and masquerading of the signal.
• Sequence counter to detect faults in the order of messages and repeated/inserted messages.
• Timer on receiver side to react on lost and delayed messages.

Shift-Left Testing

Shift-Left Testing means placing testing and quality assurance activities as early as possible in the software lifecycle - closer to requirements, architecture, and implementation instead of only at the end. The aim is to provide rapid feedback and early detection of errors using the following practices:

• Early reviews of requirements and architecture.
• Static analysis and coding guidelines directly integrated into the developer workflow.
• Continuous Integration (CI) with automated build, test, and quality gates.
• Early API and integration testing.

Why safety work is often tough - and not optional:

• Hazard and risk analysis
• Functional safety concept
• Technical safety concept
• Definition of hardware-software interfaces
• Qualitative and quantitative safety analyses
• Verification and validation
• Development processes and workflows tailored to the target market

All these activities are necessary - and they are often dry, granular, and demanding. No one does them “for fun.” But underestimating them risks costly iterations later in architecture, implementation, and certification. This is exactly where our tools and products help: they reduce complexity, standardize steps, and make the hard parts manageable.

Real-world example: Safety in multi-core embedded systems is standard today and is particularly challenging here:

• Cores must operate consistently - deterministically, reproducibly, and without side effects.
• Memory accesses must not target the wrong resources - no invalid pointers, no cross-partition interference.
• Inter-core communication must be efficient yet controlled and safety-compliant. Without the right basic software, this demands enormous discipline in architecture, configuration, testing, and evidence.

How a basic software noticeably eases your safety development:

• Enables freedom from interference in mixed systems for the interference-free execution of safety-related and non-safety-related software components on the same control unit
  •  This reduces risk, simplifies evidence for freedom from interference, and saves time in architecture and testing.
• Additional safety requirements can be mapped onto other basic software modules, such as safe and secure communication
  • This creates consistency and minimizes error risk.
• Support of multi-core microcontrollers
  • This supports clean separation of tasks, resources, and memory areas across multiple cores.
• Efficient solution for interaction between different memory partitions and microcontroller cores
  • This helps to prevent invalid accesses from the outset and ensure performance without compromising safety.
• Developed and certified in accordance with recognized standards and processes
  • This shortens your qualification and audit efforts and strengthens the chain of evidence.

The effect: Instead of building, documenting and maintaining every building block yourself, you integrate a foundation that already structurally covers freedom from interference, partitioning, safe communication, and multi-core coordination. Your safety engineering time thus shifts to truly project-specific risks and away from generic infrastructure.

What does that mean concretely in the multi-core example?

• Consistent execution: The basic software orchestrates tasks and resources per core so that safety and non-safety parts do not influence each other.
• Memory and resource protection: Clear partitions, defined HSI (hardware-software interfaces), and verified access paths prevent incorrect memory accesses.
• Evidence documents: Established modules and processes reduce the effort for verification, validation, and safety-case arguments because many requirements are already covered by the foundation and can be demonstrated in a reusable manner.

• Analyze your current safety activities (from hazard analysis to safety case) for redundancies and manual steps.
• Define architecture and process guidelines that enforce freedom from interference and partitioning from the outset.
• Pilot a setup with our basic software on a control unit especially for the segregation of components and secure communication.
• Measure the effects on development time, testing effort, and evidence strength - and scale the approach to additional projects.

Those who structure early save twice later: less rework, clearer evidence, faster releases. Start now with a focused pilot and elevate your safety development to a more efficient level.