Embedded Security In Practice: TARA and Lifecycle Plan for the FRDM-MCXN947

I picked the FRDM-MCXN947 because it carries the whole Part 1 control stack on one part you can buy for the price of a dinner. The MCX N947 is a dual Cortex-M33 with a modern security subsystem: an EdgeLock secure enclave, an SRAM PUF, ROM secure boot, authenticated debug, hardware-enforced lifecycle states, on-the-fly flash encryption, and a real crypto block. Most parts give you two or three of those. This one has the lot, on a board with an onboard debug probe and a serial console, which makes it a clean teaching target: every control Part 1 argued for in the abstract has a real implementation here, on silicon a reader can follow along with.

The plan for the series is to cast the board as an automotive Body Control Module and implement those controls one at a time. The roadmap below lists the milestones, and each traces back to a threat. This post is step one, and it does no implementation: it runs a full ISO/SAE 21434 TARA to decide which threats are worth treating, and lays out the lifecycle plan the M2-M8 milestones execute against. Every later post opens with the TARA rows it closes.

So before any of that, look at what the board does out of the box. It ships in DEVELOP state, security state UNSECURE. The boot ROM listens on six interfaces including CAN, serves 14 commands with no credential, and hands over all 2 MB of flash to any caller that asks. That is the concrete before state, read off the silicon.

In the real world of product security, you don’t often get to start at the ground floor. Unless you’re lucky enough to be in at project kickoff, you come in because security is needed but the project has already started, and you play catch-up on security controls. The architecture is usually set, and you design around it. This is where a threat model comes in: you model the system and find the gaps that need to be addressed.

The ideal is the opposite. You start the threat model during initial design and keep updating it as the design moves forward. It is always easier and more beneficial to bake security in than to bolt it on after the fact, and your threat model is what identifies the controls you actually need. That is why it is worth starting with a TARA before touching a single fuse. Threat modeling helps no matter the stage of a project, but earlier is better. This post attempts to show that. Even here, starting clean, the silicon’s architecture is already set: the feature set, the default state, the fuse map. We threat model against what the board gives us and design the rest around it.

The series roadmap

The series runs from M0 to M8. M0 is the baseline and M1 is this post; neither changes the silicon. M2 through M8 each implement one control, and each is its own post. A later section maps every milestone to the threats it closes; the table here is just the map.

Item, boundary, and the before state

The board is an NXP FRDM-MCXN947 development kit: dual Cortex-M33, 2 MB internal flash, MCUX SDK 2026.06.00 LTS, boot ROM version K3.2.0. It is not automotive-qualified silicon. We are casting it as a BCM because the security feature set (TrustZone-M, ELS S50 secure subsystem, SB3.1 signed boot, OTP lifecycle state machine) maps to what an automotive-grade MCU would implement. The cast is deliberate and bounded to this exercise.

The BCM role: receives actuation commands from the in-vehicle CAN bus and controls body functions (door locks, lighting, start-enable relay). For this TARA, the board is an ASIL B item under ISO 26262. Body-controller functions can create hazard for vehicle occupants and bystanders but this BCM does not touch motion control (braking, steering). ASIL B fits the example cast; a different BCM design might rate lower or higher depending on its functions.

Boundary: the BCM receives bus messages and actuates. The upstream RF/keyless module (PEPS/RKE) is a separate ECU, outside this item’s boundary. The BCM sees a bus message; it has no way to verify whether it originated from the legitimate smart-key ECU or from an injector. That is a boundary decision, not a gap in the analysis. The control for relay attacks belongs to a different module (see TS-upstream below).

Baseline boot

The M0 milestone established the board functioning before any security configuration:

MCUX SDK version: 2026.06.00
hello world.

cm33_core0, MCU-Link VCOM at 115200 8N1, captured live. Everything works before we touch security.

Fuse and lifecycle read

Board in ISP mode (hold SW3, tap SW1, release SW3 per UM12018 Rev 2.0), SPSDK 3.10.0 over the MCU-Link UART bridge:

=== blhost get-property 17 (security state) ===
Security State = UNSECURE

=== nxpfuses print -f mcxn947 (selected entries) ===
Name:        LIFE_CYCLE
OTP index:   0x1
Value:       0x03000003

Name:        ROTKH0   OTP 0xb    Value: 0x00000000
Name:        ROTKH1   OTP 0xc    Value: 0x00000000
  [ROTKH2 through ROTKH10 all 0x00000000]
Name:        ROTKH11  OTP 0x16   Value: 0x00000000

Factory fresh: DEVELOP lifecycle, security state UNSECURE, 75 OTP fuse entries, all zero except LIFE_CYCLE. ROTKH0 through ROTKH11 (12 words, the 384-bit root-of-trust key hash slot) are all zero: no root of trust provisioned.

LIFE_CYCLE = 0x03000003: the low byte 0x03 is LIFECYCLE[7:0] = DEVELOP; the high byte is the silicon’s redundant integrity copy. Both halves agree. CMPA and CFPA are completely erased (all 0xFF), meaning no customer security configuration exists. The CFPA parsed output shows RoTK0_EN: KEY_REVOKED_3 in some fields; that is the all-ones decode of erased flash (0xFF), not an applied revocation policy.

What the adversary gets for free

=== blhost get-property 2 (available peripherals) ===
Available Peripherals = UART, I2C-Slave, SPI-Slave, CAN, USB-HID, USB-CDC

=== blhost get-property 7 (available commands) ===
Available Commands = ['FlashEraseAll', 'FlashEraseRegion', 'ReadMemory', 'WriteMemory',
  'FillMemory', 'GetProperty', 'ReceiveSBFile', 'Execute', 'Reset', 'SetProperty',
  'FlashProgramOnce', 'FlashReadOnce', 'ConfigureMemory', 'TrustProvisioning']

=== blhost get-property 1 / 16 / 24 (bootloader / device ID / target) ===
Current Version              = K3.2.0
System Device Identification = 0x0540008B
Target Version               = T1.1.4

=== blhost read-memory 0x0 256 (unauthenticated flash readout) ===
00 e0 04 20 7d 04 00 00 15 05 00 00 19 05 00 00
11 05 00 00 11 05 00 00 11 05 00 00 11 05 00 00
...
Read 256 of 256 bytes.

=== pfr read -t cmpa / pfr read -t cfpa ===
CMPA: all 0xFF (erased).
CFPA: all 0xFF except trailing 16-byte page integrity MAC (not a secret).

The wide-open before state: six ways into a ROM that reads all of flash with no credential.

None of this surprises me. A board has to be open during development, and the MCXN947 is open by design: you need the debug port and the unauthenticated ROM to flash and iterate while you build. The concern is what comes after. Every one of these has to be locked down before a production device ships, and missing any single one is detrimental to the security of the whole device. An attacker only needs the one interface you forgot.

The CAN entry matters for the BCM specifically, and it carries two different threats. The boot ROM exposes its ISP download interface on CAN, so the unauthenticated readout above is reachable over the vehicle bus (USB and the debug port reach the same ROM commands). But it is reachable only with the part in ISP mode, and that takes a deliberate step on the board itself, which makes the ROM readout a bench, provisioning, or service threat rather than a drive-by. The threat that needs neither ISP mode nor physical custody is the running application acting on an unauthenticated CAN message and actuating a body function. That is TS1, and SecOC is its control.

read-memory 0x0 256 returned the vector table without any credential: first word 0x2004e000 (initial stack pointer), second word 0x0000047d (reset vector). On an UNSECURE part the full 2 MB reads the same way over any of the six interfaces, once the part is in ISP mode. That caveat is worth stating plainly: the ROM does not answer on a normal boot. You enter ISP mode by holding the boot pin at reset (SW3 plus the reset button on this board), which is trivial with the board in hand but is still a deliberate step, not a property of every power-on. Silicon device ID 0x0540008B, bootloader K3.2.0, target T1.1.4. (I am leaving that device ID as the raw value; decoding it to a specific silicon revision needs the Security RM.)

The TARA

The method (all seven Clause 15 activities, impact axes, feasibility rating) is in the TARA post. ATM enumeration mechanics are in the ATM walkthrough. Neither is re-taught here.

ATM source: STIX 2.1 export (77 techniques, 151 procedures). EMB3D source: live catalog. R155 source: E/ECE/TRANS/505/Rev.3/Add.154, Annex 5.

15.3 Assets

Five assets are worth protecting:

1. Firmware IP (proprietary application code, 2 MB flash at 0x0, currently plaintext)
2. Root-of-trust key hash (ROTKH in the OTP fuses, mirrored as RKTH in the CMPA; currently all zero)
3. Device identity (128-bit UUID, per-die; redacted from capture)
4. Data at rest (plaintext flash; no PRINCE encryption active in DEVELOP state)
5. Body-function actuation authority (the BCM’s ability to unlock doors and enable start based on bus commands it receives)

The fifth asset is the one the frameworks handle least gracefully. The first four are device-level properties; actuation authority is systemic to the network architecture. More on that in the framework-strain section.

Threat scenarios, attack paths, and treatment

Adversary tiers. Three tiers cover the realistic attacker population for a wired BCM. T1 is a remote attacker reaching the board over the in-vehicle bus from another ECU or a connected diagnostic tool, with no physical board access. T2 has physical access to the CAN harness or OBD port. T3 has the board in hand with UART/SWD and bench equipment. Fault injection and side-channel attacks go beyond T3; they are a real, acknowledged threat this series does not treat in M2-M8. TID-105 and TID-110 (EMB3D) and T0028 (ATM) are named below under TS5 precisely because ignoring them would be wrong. The Leading-tier hardware countermeasures (EMB3D MID-062) are the second conversation, scoped for a later phase after the foundational controls are in place.

Damage scenarios (author’s signed calls):

D1: An attacker delivers an unauthenticated bus command that causes the BCM to unlock a door or enable start. Safety impact: Moderate (ASIL B body function, no motion control). Financial, Operational, Privacy impact: Major (vehicle theft; fleet availability; occupant privacy).

D2: An attacker overwrites BCM firmware to plant persistence or defeat body functions. Safety impact: Moderate (same ASIL B framing). Operational impact: Major (fleet-wide effect if a shared signing key was involved).

Both damage scenarios rate Safety as Moderate, and that is worth defending, because the reflex is to rate any attack on a car as catastrophic. A body control module actuates door locks, lighting, and start-enable. It does not steer, brake, or drive the powertrain while the car is moving. An attacker who unlocks a door or enables start has beaten the theft protections, which is a real and expensive problem, but has not taken control of a moving vehicle. That is the line between an ASIL B body function and the ASIL C or D functions that govern motion, and the severity class has to follow the function. Rate the BCM for what it does, not for the worst thing some other ECU on the bus could do. The financial, operational, and privacy impacts are where these scenarios actually bite: D1 is the mechanism behind a generation of keyless thefts, and D2 turns one compromised unit into a foothold, or into a fleet-wide problem the moment a shared signing key is in the picture.

Attack paths. Four concrete paths connect scenarios to steps:

AP1 (TS1 via CAN injection, T1/T2): An attacker splices into the CAN bus and injects a forged frame impersonating the smart-key ECU’s unlock or start-enable message. The BCM receives a valid-looking bus message and actuates. Ken Tindell’s 2023 writeup of the Toyota RAV4 theft (Canis Labs) documents exactly this path: thieves reached the CAN bus through the headlight wiring loom and spoofed the smart-key module’s frame. The BCM is the actuating endpoint; it did exactly what it was told. Those vehicles did not authenticate the smart-key module’s CAN frames; SecOC is the countermeasure that would have broken the attack. Maps to T0071 + upstream T0007.

AP2 (TS3 + TS2, T3): Physical SWD access with the board in DEVELOP state. LinkServer connects with no authentication challenge, dumps the full 2 MB flash, and can write modified firmware. Also reachable over CAN ISP with ReadMemory / ReceiveSBFile in the same state. Maps to T0016, T0022.

AP3 (TS1 via diagnostic, T2): OBD connector, UDS RoutineControl or InputOutputControl session targeting a body-function output. The diagnostic path requires only OBD port access, not board custody. Maps to T0067.

AP4 (TS5, T3+): Board in hand, voltage or EM glitch timed against the boot ROM signature check to skip or corrupt the integrity verification. The μ-Glitch platform (USENIX Security 2023) demonstrated coordinated multi-fault voltage fault injection on NXP TrustZone-M parts including the LPC55S69. The MCXN947 was not among the tested chips; its ELS S50 adds hardware isolation beyond what the LPC55S69 has. The threat is the class, not a confirmed per-device vulnerability. ESP32 CVE-2019-15894 (voltage glitch, per LimitedResults) and CVE-2020-13629 (EM glitch, per Raelize and Espressif’s advisory; the NVD record is reserved) are the closest public precedents for this attack class on commercial MCUs. Fusée Gelée (CVE-2018-6242) is the ROM-level immutability lesson: a bug in mask ROM is unrecoverable.

Feasibility and risk values. Feasibility follows the ISO/SAE 21434 attack-potential method (elapsed time, expertise, item knowledge, window of opportunity, equipment); the method is in the TARA post. These are untreated ratings, the case that justifies each control.

TS1 is High. CAN injection and UDS actuation need access to the harness or the OBD port and little else: the technique is public, the equipment is cheap, and the attack has already been industrialized into theft tools sold online. Low expertise, low cost, short time. That is why TS1 carries the highest risk in the table even though its safety impact is only Moderate.

TS2 and TS3 are Medium, gated by physical access to the part, the debug pads, or the bus in ISP mode. Once there, the DEVELOP-state part asks for no credential, so expertise and equipment stay low. Physical access is the barrier, and raising it is exactly what M2 and M3 do.

TS4 is Medium against keys sitting in plaintext flash and Low once they live in the ELS. That gap is the whole argument for M4: a key the application core never sees in the clear is a far harder target than one in a readable flash region.

TS5 is Low. Fault injection needs bench equipment, device-specific glitch tuning, and real expertise, and the ELS S50 raises the bar past what the LPC55S69 work required. Low feasibility is why it lands at Risk 2 and stays the second conversation, not because the threat is unreal.

The relay attack (TS-upstream) is High feasibility in the wild but sits outside the BCM boundary; its risk belongs to the PEPS/RKE module, not this part.

Risk combines worst-case impact with feasibility on a 1-to-5 scale, shown in the summary below.

From threats to milestones

Each later post in this series opens with the TARA rows it closes. The table below maps each control to the threats, EMB3D TIDs, ATM techniques, and R155 anchors that motivated it. M1 is this post.

TS1 (bus message authentication) and TS-upstream (relay) sit outside M2-M8. The standard control for TS1 is SecOC (AUTOSAR Secure Onboard Communication): it appends a truncated MAC plus a freshness value (a monotonic counter or timestamp, for anti-replay) to protected CAN/CAN-FD frames, giving authenticity, integrity, and replay protection. That is what R155 M10 (“verify authenticity and integrity of received messages”) looks like in practice. SecOC is symmetric-key: sender and receiver ECUs share keys, so key distribution and storage matter. ATM-P0196 (“Extracting SecOC secrets from an ECU”) is the procedure that targets those shared keys, which is exactly why M4 (hardware key storage, ELS AES-CMAC, TRNG for key and freshness seed generation) is a prerequisite for any SecOC deployment here. The SecOC protocol itself, freshness management, and symmetric-key distribution are communications-security concerns this hardware-focused series names and defers to a later post. TS5 Leading tier (EMB3D MID-062) is the explicit second conversation.

Lifecycle state machine

The lifecycle plan

The series advances the part through three states and stops there.

DEVELOP (M1, now). The current board read. UNSECURE, 74 of 75 OTP fuse entries blank, SWD fully open, ISP on all six interfaces, no root of trust. Everything above is the documented evidence of this state.

DEVELOP2 (M2). M2 provisions the root-of-trust key hash. SPSDK writes the ROTKH fuse words (OTP 0xb through 0x16, 12 words, sized to hold a 48-byte P-384 hash or a 32-byte P-256 hash) and copies the RKTH into the CMPA. Secure boot is enabled: from this state on, the boot ROM verifies every image against an SB3.1 container signed with ECDSA P-256 (SHA-256) or P-384 (SHA-384). The lifecycle OTP advances from 0x03 to 0x07 by burning additional bits.

IN_FIELD (M3). M3 configures authenticated debug via the DCFG_CC_SOCU fields and locks the ISP interfaces. Debug does not go fused-off. The DAT (Debug Authentication Token) flow stays enabled: the board issues a 32-byte challenge, the debug host presents a Debug Credential containing the host’s public key, signs the challenge, and returns the response; the board verifies against the credential before granting access. The lifecycle advances from 0x07 to 0x0F. This series steps through DEVELOP2 on the way to IN_FIELD; whether the part can also jump straight from DEVELOP to IN_FIELD is a Security-RM detail that does not change the plan.

FIELD_RETURN_OEM remains available throughout the series for RMA. A properly credentialed return flow can re-open a limited debug path without leaving debug permanently accessible.

The series does not reach IN_FIELD_LOCKED (0xCF). That state closes the FIELD_RETURN path and prevents the part from ever entering field-return or failure-analysis states. It is the right production posture for a device that should never be debuggable by anyone. For this series, ending at a recoverable device is the deliberate choice: every transition is human-in-the-loop, and the goal is demonstrating the progression, not producing a brick.

The MCUXpresso Secure Provisioning Tool shows “OEM Open” for DEVELOP and “In Field ROP 1/2/3” labels in its GUI. The OTP fuse holds only two in-field values (IN_FIELD 0x0F and IN_FIELD_LOCKED 0xCF); the ROP 1/2/3 labels describe a ReadOut Protection layering on top of the in-field state, not three distinct fuse values. The exact ROP-to-state mapping is in the Security RM.

Read the current state at any time (read-only, no board change):

PORT=/dev/cu.usbmodemXXXX            # your MCU-Link VCOM port
blhost -p "$PORT" get-property 17    # security state
nxpfuses print -f mcxn947 -p "$PORT" # full OTP map + LIFE_CYCLE

Where the frameworks strain

Using ATM and EMB3D together on a wired actuating BCM exposed two genuine gaps, one in the catalogs and one in the scope framing.

The actuating-victim gap. ATM T0071 “Unintended Vehicle Network Message” describes the injector side: how an attacker plants a forged message on the bus. EMB3D covers device-firmware exploitation and physical fault attacks. Neither has a threat entry for a downstream ECU that receives a bus command and actuates it without verifying the message’s origin. The BCM’s most direct exposure (a correctly functioning device doing exactly what it was told by a forged message) sits between both frameworks. The threat and its standard fix are both named in the relevant standards: R155 11.1 covers the threat, M10 names the required control, and SecOC (AUTOSAR Secure Onboard Communication) is the standard implementation. ATM even has ATM-P0196 for attacking SecOC keys. The injector and the key thief are modeled. The victim ECU that acted on a message it couldn’t authenticate is not.

That is the friction. The control lives in R155 and the AUTOSAR communications stack, not cleanly in either threat matrix. A threat assessment drawn exclusively from ATM and EMB3D will name every technique the injector uses and miss the actuating endpoint entirely. The gap is not a cataloging error in any one framework; it reflects where the architecture sits: the BCM is a net consumer of bus authority, and the mechanism for challenging message authenticity (SecOC) belongs at the communications layer, not the device firmware layer.

ATM’s physical-access density. The technique catalog skews toward radio and cellular initial access. AP1 through AP3 all require physical access to the CAN harness or the OBD port. That is a meaningfully higher real-world barrier than a remote attacker. The BCM-relevant techniques are in the matrix (T0016 Physical Modification, T0010 Aftermarket/Dealer Equipment), but the catalog’s breadth makes it easy to overweight remote vectors when scoping a wired actuator with no external network connection.

Further reading and what’s next

M2 is next: provisioning the ROTKH fuses, building and signing the SB3.1 container with SPSDK 3.10.0, and burning the lifecycle to DEVELOP2 on this board. Every subsequent post opens with the TARA rows from the table above that it closes.

Prior posts in this series:

• Embedded Security In Practice (Part 1): why secure boot, debug lockdown, key storage, and isolation each exist.
• ISO/SAE 21434 TARA method: all seven Clause 15 activities on a telematics backend, plus where the method strains.
• Automotive Threat Matrix walkthrough: scoping ATM to one ECU, technique selection, and what the matrix is not.

Primary sources (retrieval dates given for live catalogs):

• NXP MCX Nx4x Security Reference Manual, Rev 5, 2025-05-19
• Automotive Threat Matrix STIX 2.1 export, Auto-ISAC (77 techniques, 151 procedures)
• MITRE EMB3D catalog
• UN Regulation No. 155, E/ECE/TRANS/505/Rev.3/Add.154, Annex 5 Parts A and B
• Ken Tindell / Canis Labs, “CAN Injection: keyless car theft,” April 2023
• USENIX Security 2023, “Oops..! I Glitched It Again!” (μ-Glitch, NXP LPC55S69 fault injection)
• SPSDK 3.10.0