A marine bridge computer that hosts ECDIS, AIS, chart-radar overlay, voyage data, and increasingly classified video has become a real target. Cyber regulations now sit alongside environmental ones: IACS Unified Requirements UR E26 and UR E27 took effect for newbuild ships with first survey on or after July 1, 2024, and defense procurement has required hardware roots of trust on every classified-handling console for years. The Trusted Platform Module is the small chip that lets a computer prove its software has not been tampered with, hold disk-encryption keys outside the operating system, and resist a compromised OS. This article walks through when a marine computer TPM is actually required, which class of TPM fits a bridge build, and how to specify one for procurement so a refit or newbuild can pass a cyber survey on the first attempt.
What Does a TPM Actually Do on a Marine Bridge Computer?
A Trusted Platform Module is a discrete cryptographic chip (or a firmware-isolated equivalent) built to the ISO/IEC 11889 specification, currently at version 2.0. On a bridge computer it performs four jobs that the host operating system on its own cannot reliably perform.
First, it stores cryptographic keys in tamper-resistant silicon. Endorsement keys, storage root keys, attestation identity keys, and application-sealed keys live inside the chip and never leave it in cleartext. Second, it measures the boot chain. Every component the firmware loads (option ROMs, UEFI drivers, the bootloader, the kernel image, signed driver packages) is hashed and that hash is extended into one of the TPM Platform Configuration Registers. Third, it can seal data against a specific boot state. A chart certificate, a BitLocker volume key, or an ECDIS S-63 user permit can be unsealed only when the running PCR values match a known-good configuration. Fourth, it can sign an attestation quote that an external verifier (a fleet manager ashore, a class-society auditor, or a defense network controller) can use to confirm the computer booted into the expected state.
Two forms of TPM and why the distinction matters at sea
A discrete TPM (dTPM) is a separate integrated circuit on the motherboard, typically an Infineon SLB 9670 or 9672, an STMicroelectronics ST33 series part, or a Nuvoton NPCT75x. It has its own packaging, its own certification, and a clear physical boundary that a defense procurement officer or a class-society auditor can point to. A firmware TPM (fTPM) runs inside the host CPU’s security engine: Intel Platform Trust Technology on Intel SKUs, AMD fTPM on AMD platforms, ARM TrustZone-backed implementations on embedded ARM boards.
Both implementations satisfy the same TPM 2.0 software interface, so an operating system cannot easily tell which one it is talking to. The procurement difference is real, though. A discrete TPM has its own FIPS or Common Criteria certification independent of the CPU. A firmware TPM shares the host CPU’s certification scope, which means a published CPU-level vulnerability can compromise the TPM. For safety-critical bridge compute that has to survive a 10-15 year service life, the discrete chip is the lower-risk path even when the BIOS exposes both.
When Does Maritime Compliance Require a TPM?
The short answer is that no current rule names a TPM as a literal mandatory component. The longer answer is that several rules now require capabilities that, in practice, only a TPM provides cleanly, and surveyors are starting to look for it.
IACS Unified Requirement UR E26 (cyber resilience of ships) and UR E27 (cyber resilience of onboard systems) took effect for newbuild contracts with first survey on or after July 1, 2024. They require secure boot, software integrity verification, controlled access to system functions, and protected key storage on safety-critical onboard systems. None of those clauses name a TPM, but a hardware root of trust is the only practical way most vendors can prove the secure-boot chain and key-storage requirements in a survey. IMO Resolution MSC.428(98) layered cyber risk management into the safety management system at the company level. Class-society notations such as the Cyber Resilient notation from major societies are starting to inspect the integrity-verification chain directly, not just paperwork.
On the defense side the picture is sharper. DoDI 8500.01 requires cybersecurity protections on every information system. NIST SP 800-147 (BIOS Protection Guidelines) and SP 800-193 (Platform Firmware Resiliency) effectively assume a hardware root of trust on the platform. Programs handling classified video or sensor data routinely require FIPS 140-2 Level 1 (and often Level 2) certified cryptographic modules, which on a typical x86 bridge console means a discrete TPM 2.0 in a hardened package. Naval communications and combat-direction-system integrations that fall under MIL-STD environmental envelopes also pull in TEMPEST and red-key handling, which assume sealed-key storage at the platform level. The full MIL-STD environmental tests a bridge or tactical-console build has to pass already pull procurement toward purpose-built hardware; TPM provisioning is the security-side companion to that environmental program.
The practical procurement question
For a newbuild commercial vessel whose first survey lands after July 2024, the realistic answer is that the bridge computer needs a TPM 2.0, provisioned and active, even if no rule sentence names the chip. For a retrofit on an older vessel, the trigger is usually flag-state policy, a class-society cyber notation, a fleet-level cyber policy, or a charterer requirement. For defense and government work, the RFP language will state the TPM and certification level explicitly, and missing it disqualifies the bid.
Where Does a TPM Fit in the Marine Bridge Compute Stack?
The TPM is not a standalone product; it is the anchor of a verification chain that starts the moment power hits the board and only ends after the application is loaded. Understanding the chain is the difference between procuring a bridge computer that passes a cyber survey and procuring one with a TPM populated but not actually used.
The chain begins at UEFI firmware. UEFI Secure Boot verifies the bootloader signature against a platform key set that the TPM helps protect. The bootloader (Windows Boot Manager, GRUB, systemd-boot, or a vendor-signed equivalent) verifies the kernel signature. The kernel verifies driver and module signatures. The operating system loads, measures, and seals application-layer state. ECDIS chart certificates and S-63 user permits can be sealed against the TPM PCRs so they unseal only when the boot state matches a known-good measurement. Voyage Data Recorder write integrity can be signed by the TPM, making post-incident tampering provable in a board-of-inquiry review.
TPM and the operating system on the helm
Operating system choice directly shapes the TPM driver stack. Windows 11 IoT Enterprise LTSC requires TPM 2.0 for installation, and BitLocker volume encryption uses the TPM as the default key custodian. Embedded Linux distributions implement TPM 2.0 through tpm2-tools, tpm2-tss, and clevis for unattended LUKS unlock; dracut-fips integrates the TPM into the initramfs measurement path. VxWorks and QNX expose TPM 2.0 through partner integration packages and security middleware. The long-term firmware support window on a bridge OS is the constraint that should drive TPM driver selection, because a TPM firmware update without a matching OS driver stack will brick the security chain in the field.
One common procurement oversight is shipping a bridge computer with a TPM present on the board but disabled in BIOS. The factory image runs, the survey paperwork lists “TPM 2.0 supported,” and the chain is never measured. Vendors should be required to deliver a unit with the TPM enabled, owned, and provisioned, with the endorsement key archive included in the documentation pack.
Sealed storage for chart and voyage data
The TPM is also the cleanest key custodian for full-disk encryption. A self-encrypting drive (SED) on a bridge computer can use the TPM to hold the data encryption key, replacing a password the watch keeper might tape inside the console. ECDIS S-63 user permit keys can be sealed against PCR values that capture both the firmware and the chart-display application, so an attacker who replaces the chart engine with a tampered binary cannot read the permit out. The same approach extends to self-encrypting storage selection: when the TPM and the SED are specified together, the bridge computer can survive theft of the drive, theft of the chassis, and most offline attack scenarios.
How Should You Specify a TPM for Marine Bridge Procurement?
The TPM line item on a marine bridge computer specification should answer five questions: which type, which certification level, which bus, which lifecycle, and how it will be provisioned and recovered.
TPM type and certification
For commercial newbuilds, a discrete TPM 2.0 from Infineon (SLB 9672, SLB 9670), STMicroelectronics (ST33HTPHA2X, ST33KTPM2X), or Nuvoton (NPCT75x) on an LPC or SPI bus is the conservative baseline. All three families carry Common Criteria EAL4+ certification and FIPS 140-2 Level 1 certification, which is adequate for commercial cyber resilience scope. For defense, government, and intelligence procurement, a FIPS 140-2 Level 2 certified TPM with active tamper detection and zeroization on intrusion is the typical bid floor; Level 3 certified parts appear on classified-handling consoles and red-key fill devices. Firmware TPM is acceptable for general-purpose embedded compute but should be avoided for any computer that hosts ECDIS, VDR write paths, classified video, or fleet-attestation endpoints, because a CPU-level vulnerability collapses the security boundary.
Lifecycle and firmware support
A bridge computer typically stays in service for 10 to 15 years. The TPM has to stay in security update support for that entire window. Industrial silicon vendors publish lifecycle commitments of 10 to 15 years on embedded TPM SKUs; mainstream consumer parts do not. The same lifecycle discipline that drives CPU selection in the core processor selection decision applies to the TPM: spec the embedded SKU, document the end-of-life date in the procurement package, and budget for a planned mid-life refresh rather than a panic swap after a public vulnerability disclosure.
Connector, bus, and integration
The motherboard has to actually expose the TPM in a way the OS can use. The Low Pin Count (LPC) bus is the legacy connector and is still widely supported. Serial Peripheral Interface (SPI) is the current standard on modern embedded boards and is faster with a lower pin count. I2C TPMs appear on some ARM platforms and on lower-cost embedded designs. Verify the board includes the right TPM header before procurement; not every embedded board with a “TPM-supported BIOS” actually has the pin header populated. If the TPM is co-located with an HSM or red-key fill device on a defense build, the integration drawing should be reviewed alongside the rest of the I/O bus map, not bolted on after the fact.
Provisioning, key management, and recovery
TPM ownership transfer should follow ISO/IEC 11889 procedures and be performed during commissioning, not in the yard’s general IT room. Endorsement keys are factory-installed and must be archived under controlled access. The storage root key and attestation identity keys are generated during commissioning. Most importantly, a documented recovery procedure must exist BEFORE the vessel leaves the yard. A failed TPM update, an unexpected hardware change, or a forgotten owner password can lock the TPM at sea, and without a recovery plan the bridge computer is effectively bricked until the next port call. The cyber response plan should treat TPM recovery the same way the engineering response plan treats main-engine starting-air loss: pre-staged tools, known procedure, signed-off authority.
What Are the Limits and Failure Modes of a Bridge TPM?
A TPM is not a complete cyber strategy. It anchors integrity at the platform level, but the surrounding policies, network architecture, and operational procedures still have to be sound. The limits and failure modes that a bridge electrician or fleet IT lead should plan for are specific.
TPM lockout
The TPM enters a dictionary-attack lockout state if too many invalid authorization attempts are made. It also enters an undefined state if PCR values change unexpectedly (a BIOS update, a kernel update without measurement registration, or a hardware change such as a swapped storage drive). Plan for both: keep a factory recovery image accessible, document an offline TPM clear procedure, and pre-stage a USB key with the recovery tooling so the bridge engineer is not improvising at 0300 in heavy weather.
Hardware failure rates
TPMs are robust. Reported failure rates from industrial silicon vendors sit in the low single digits per million part-hours under normal conditions, well below the failure rate of the surrounding storage and DC-input components. Even so, the failure rate is not zero, and a TPM failure typically means a full module swap because the chip is soldered to the board. For mission-critical military deployments, redundant compute modules with independent TPMs are standard; for commercial bridges, a documented swap-out timeline with the vendor is usually enough. Either way, the failure case has to be drilled before sea trials so the vessel does not learn the procedure under pressure.
Decommissioning and disposal
A TPM holds cryptographic material that survives a reformat. Before a vessel is sold, a bridge computer is returned for refurbishment, or a hardware refresh removes a unit from service, the TPM must be cleared. Document the TPM clear and SED secure-erase procedures together in the cyber response plan so neither step is skipped. Defense decommissioning often requires destruction of the TPM silicon, not just a clear command; budget for that step in the platform refresh plan.
Where Should TPM Spec Work Begin for a Bridge Refit?
Start with the regulation map. Flag-state cyber requirements, the classification society notation the owner has elected (or is being asked to elect by a charterer), the IACS UR E26 / E27 scope for newbuilds, and any defense RFP language define the minimum TPM type and certification level. Map the operating system next, because Windows IoT, embedded Linux, VxWorks, and QNX each carry a different TPM driver and management stack. Pick the silicon third: discrete TPM 2.0 for commercial newbuilds, FIPS 140-2 Level 2 (or higher) for defense and government work, firmware TPM only for general-purpose compute that is not on the safety-critical bridge LAN. Provision and document the recovery procedure before sea trials, not after. When the regulatory map, OS stack, and TPM specification are all aligned, the bridge compute build slots cleanly into the high-performance marine computer lineup that already meets the environmental, power, and ingress sides of the same procurement window.
Frequently Asked Questions
Is a TPM required for ECDIS type approval?
No type approval rule names a TPM as a literal requirement. The IEC 61174 ECDIS performance standard governs the chart-display application, not the hardware security module. However, IACS UR E26 and UR E27 require secure boot, integrity verification, and protected key storage on safety-critical onboard systems for newbuilds with first survey on or after July 1, 2024. On a typical x86 ECDIS compute platform, those requirements are satisfied with a TPM 2.0, so newbuild ECDIS bridges are effectively shipping with TPMs even though the type approval does not name the chip.
What is the difference between TPM 2.0 and TPM 1.2 on a bridge computer?
TPM 2.0 is the current ISO/IEC 11889 specification. It supports modern cryptographic algorithms (ECC P-256 / P-384, SHA-256 and above, RSA 2048+), multiple hierarchies, and platform-defined PCR banks. TPM 1.2 is the older specification limited to SHA-1 and RSA, with a single hierarchy. SHA-1 is no longer acceptable in most cyber procurement scopes, and TPM 1.2 silicon is past end of life at all major vendors. A bridge computer being procured in 2026 should be TPM 2.0; a TPM 1.2 unit being kept in service is a refresh candidate.
Can a vessel use firmware-based TPM instead of a discrete chip?
Technically yes; practically, only for general-purpose embedded compute that is not on the safety-critical bridge LAN. Firmware TPM shares the host CPU’s security boundary, so any CPU-level vulnerability (and several have been disclosed over the last decade) collapses the TPM trust chain. For ECDIS, VDR, classified video, and fleet attestation, a discrete TPM is the lower-risk choice and the one most surveyors prefer to see populated and certified.
Does IACS UR E27 require a TPM specifically?
No. UR E27 sets functional requirements: secure boot, integrity verification, controlled access to system functions, protected key storage, and event logging. It does not name a TPM. In practice, on a commodity x86 or ARM compute platform, a TPM 2.0 is the cleanest path to meeting those clauses in a way that survives a cyber survey. Class societies that have published interpretive guidance under E26/E27 routinely cite hardware roots of trust, and TPM 2.0 is the standing implementation of that capability in shipboard compute.
What happens if a TPM fails at sea?
The behavior depends on how the boot chain was provisioned. If the OS is configured for TPM-required full-disk encryption with no recovery key staged, the bridge computer will not boot until the recovery procedure runs. If the TPM is configured for measured boot with a fallback path (signed offline boot media, vendor recovery image), the computer can still boot but will log the integrity failure and require remediation at the next port call. Document the failure path in the cyber response plan, stage a USB recovery key in a sealed envelope with controlled access, and drill the procedure before sea trials.
How long does TPM key material remain valid?
Endorsement keys are factory-installed and are valid for the life of the chip. Storage root keys and attestation identity keys are generated during commissioning and remain valid until the TPM is cleared or the chip fails. Application-sealed keys remain valid only as long as the sealing PCR values match the current boot state; a firmware update or an OS kernel update that changes those PCR values invalidates the sealed material until the application re-seals against the new state.
Can BitLocker on a Windows IoT bridge computer use a TPM?
Yes. BitLocker on Windows IoT Enterprise LTSC uses TPM 2.0 as its default volume key custodian. The TPM seals the volume master key against PCR values that capture the firmware, bootloader, and kernel measurements, so the volume only unlocks on a verified boot. Configure a recovery key path and store the recovery key in the fleet operator’s key management system, not on the bridge or in the same console where the computer lives.
Should a defense bridge console use a Level 1 or Level 2 FIPS-certified TPM?
Defense bid floors usually start at FIPS 140-2 Level 2 for consoles that touch classified video, sensor data, or combat-direction-system streams. Level 2 adds active tamper-detection and zeroization on intrusion, which is the bar most procurement officers expect on a hardened bridge or CIC console. Level 1 is acceptable on logistics, training, and general-purpose embedded compute that is not in a classified-handling path. Always confirm the certification level against the RFP language before committing the silicon.