There is a recurring moment in software intensive medical device projects that I came across several times. The software team has its process, regulatory has its templates, the project manager has an optimistic Gantt chart, and the hardware platform underneath is treated as an implementation detail. One SoC is much like another, Linux runs on top anyway.
Then the audit arrives, or somebody goes deeper in the risk analysis, or a CVE lands on a library that lives inside the bootloader. At that point the implementation detail becomes the subject of three half-day meetings a week.
NXP’s i.MX9 series has several characteristics that materially change how much work you have to do in a regulated medical context. Not all of the ones marketing puts on the front page, and not always for the reasons marketing gives.
First, let us untangle the classes
When people normally say Class II and Class III they are using the FDA device classification. In Europe the MDR uses I, IIa, IIb and III, and these do not map one to one. Neither of them directly translates to IEC 62304 software safety classes A, B and C, which depend on the severity of possible harm after risk controls, external to the software, have been applied.
The confusion between these classifications is common enough to be worth clarifying. A Class III device can contain Class A software items, and a Class II device can contain Class C ones. Severity of harm decides, not the intended use of the apparatus.
Once this is understood, it becomes clear why hardware architecture matters. Hardware certifies nothing on its own, however it decides how easy it is to defend the choices you made on top of it.
Domain segregation, and the myth worth busting
IEC 62304 allows different software items to carry different safety classes, provided the segregation is effective and backed by a documented, credible rationale. Amendment 1 from 2015 explicitly clarified that segregation does not have to be physical. Anyone telling you that separate hardware is a regulatory requirement lives with the dinosaurs.
That said, there is an enormous practical gap between writing a rationale about software isolation and writing one about hardware isolation. In the first case you are arguing that two processes sharing a core, an MMU context switch and a scheduler cannot influence each other. In the second you point at two distinct cores with their own memory space and independent clock and power domains, and the argument closes in half a page.
On i.MX93 you get an application domain with up to two Cortex-A55 cores and a real-time domain with a 250 MHz Cortex-M33, in a 9x9mm package, with the Energy Flex architecture managing clock and power for each domain independently. The M33 sits in the always-on domain, and NXP’s own low power modes describe the A55 fully powered down with DRAM in self-refresh while the M33 keeps handling computation and peripherals. When you are writing a segregation rationale, a real-time domain that survives the application domain being switched off is a very short paragraph to write. The system can also boot from either domain, which opens some interesting conversations about who owns the start of the chain.
On i.MX95 the scale goes up. Up to six Cortex-A55 cores at 2.0 GHz in the application domain, one Cortex-M7 at 800 MHz, and one Cortex-M33 at 333 MHz configurable as a safety island. It is the first i.MX to support functional safety in a structured way, developed under the NXP SafeAssure programme targeting ASIL-B for ISO 26262 and SIL-2 for IEC 61508.
Honesty is required here, because this is where marketing usually slips. ASIL-B and SIL-2 are not medical certifications; there is no shortcut that lets you skip the notified body. What you get is a supplier who has already produced structured safety documentation for that silicon, and a good portion of that material enters your risk file as supporting evidence rather than you having to describe how it works. Given that IEC 61508 is the functional safety standard that IEC 62304 adapts for the medical sector, and which it cites as a source of sound development practice, the material enters your risk file as supporting evidence, once you have mapped it onto what 62304 actually asks for.
On the practical side, anyone who has taken an i.MX9 to production on a custom board knows that power sequencing between domains and fuse programming are not for the faint of heart. In my case I build on pre-validated Variscite VAR-SOM or DART SOMs, from a manufacturer that is ISO 13485 certified and has already worked their asses off on my behalf on the low-level.
Hardware security, the chapter nobody volunteers to write
Since 29 March 2023, Section 524B of the FD&C Act requires premarket submissions for cyber devices to include an SBOM, a postmarket vulnerability management plan, a coordinated disclosure process and evidence of secure by design development. The FDA can refuse to accept the submission outright if it is missing. In Europe, EN IEC 81001-5-1:2022 covers the same on the lifecycle side and has become the de facto reference for MDR Annex I sections 17.2 and 17.4.
All of that is software and process. The hardware piece underneath is considered as the root of trust.
On i.MX9 that piece is the EdgeLock Secure Enclave, a self-contained subsystem with its own core, ROM and RAM, plus crypto accelerators with side channel countermeasures. In older NXP docs you will also find it as ELE, Sentinel and S400, because the name changed three times in three years and the U-Boot sources still use them interchangeably, an evil detail that already cost me several hours of frustration and swearing.
Secure boot goes through AHAB. You sign the containers, program the SRK table hash into the fuses, confirm that ahab_status reports no events, and only then blow the SEC_CONFIG fuse to close the device. That last step is one time programmable, so you either get it right first time or your SoC goes straight to the dumpster. On i.MX9 the mechanism also supports revocation of SRK1 through SRK3, which means you can rotate keys in the field while preserving the chain of trust, a brilliant choice for a device with a fifteen year service life.
On i.MX95 the enclave arrives in Advanced profile with post-quantum support, hybrid ML-DSA plus ECDSA for NXP signed firmware. If you are designing something today that will still be in the field by 2040, it is worth knowing your supplier has already started that migration.
And this is where the hardware stops helping. An isolated real-time domain with flawless secure boot, running a firmware built without a traceable process, is an advantage that exists only in marketing material; under EN IEC 81001-5-1 the security activities have to be demonstrated by evidence across the whole lifecycle, and an SBOM cannot be generated retroactively the day before submission. This is why, when a project calls for it, I work with trusted people already developing embedded software under ISO 13485: namely NRG. The silicon gives you the isolation, the process gives you the ability to make it work.
Random faults, the part software cannot mitigate
IEC 60601-1 introduces essential performance, the functions whose loss or degradation results in unacceptable risk. In practice, plenty of random hardware faults get waved away during risk management with a vague “the software will catch it”, which holds only if the software is running on memory that has not just flipped a bit on its own initiative.
i.MX93 implements ECC on the Cortex-A55 L1, L2 and L3 caches, on the Cortex-M33 TCM, on internal on-chip memory and on the DDR interface. i.MX95 extends the same approach, including ECC on the M33 and M7 subsystem caches and TCM. These features directly show up in MTBF numbers and in FMEDA analysis.
Then there is the part with no regulatory content but enormous practical consequence: routing LPDDR4 around the i.MX9 BGA package leaves no room for signal integrity mistakes. The shortcut you take there does not show up on the bench at 25 degrees, you see it in the anechoic chamber during EMC testing, or six months later on a production lot built with a slightly different DRAM supplier. That is another reason a SOM pays for itself in a regulated project.
Fifteen years, in medical is not that long
NXP commits to a minimum of ten years availability for products in its longevity programme, rising to fifteen for part numbers aimed at the automotive, telecom and medical segments, but history tells us that they continue to support widely used products well beyond those boundaries.
Combine that with an LTS kernel or a CIP baseline on Yocto and you have a platform you can maintain, security-wise, across the entire device lifecycle without a hardware redesign. Which is precisely what Section 524B expects you to demonstrate when it asks for a postmarket vulnerability management plan, by the way.
Watch out for the mouse trap: if the silicon is guaranteed for fifteen years but the module carrying it is guaranteed for five, obsolescence has just been relocated one level up and made harder to see. Ask your SOM supplier what their declared availability horizon is, again Variscite keeps you in the long run.
OK, hardware does a lot, what’s left?
The i.MX9 platform certifies nothing. No SoC does, and anyone telling you otherwise is selling.
What it does is move a measurable amount of work from the “to be demonstrated” column to the “already documented by the supplier” column. Domain segregation gives you a defensible rationale. EdgeLock Secure Enclave gives you a root of trust you do not have to invent. ECC gives you a mitigation for a class of faults that would otherwise sit in your residual risk table. Longevity gives you the right to promise maintenance without crossing your fingers and hope for the best.
The rest is the whole chain: silicon, module, firmware, software, process. If any one of those five links has no documented history behind it, the audit will find it and reject your application.
In the end nobody audits a PCB. They audit everything that turned out to depend on it.
If you’re evaluating the development of a regulated embedded platform and want to talk through the architecture before it becomes a documentation problem, get in touch.