Hardware-rooted identity for industrial control systems.
IEC 62443 sections 4-1 and 4-2 mandate hardware-anchored device identity, secure boot integrity, and lifecycle credential management. TigerTrust's TPM 2.0 attestation, IEEE 802.1AR DevID, and PCR-gated issuance map directly to those controls.
SL3 and SL4 require hardware roots of trust — not paperwork.
IEC 62443 Security Levels are cumulative. SL1 defends against casual violation; SL4 defends against nation-state adversaries. Hardware-backed key storage and remote attestation become effectively mandatory at SL3 and above.
- Device identity anchored in software-only credentials — no way to prove hardware residence
- Secure Boot state never verified before certificate issuance
- Manual key generation and distribution procedures with no audit trail
- Cloned or spoofed device identities indistinguishable from real ones
- Auditors reject the CR 1.2 / CR 3.3 evidence as insufficient for SL3
- CR 1.2 satisfied by TPM 2.0 attestation and IEEE 802.1AR IDevID
- CR 3.3 satisfied by PCR-gated issuance verifying Secure Boot and firmware state
- CR 1.5 satisfied by automated key lifecycle with HSM-backed CA private keys
- CR 3.5 satisfied by machine-readable audit trails for every issuance and attestation
- Golden PCR baselines captured per firmware version and enforced automatically
Secure product development lifecycle
The process standard for product vendors: security requirements definition, threat modelling, secure design, and cryptographic key generation / distribution / destruction procedures.
- Documented key generation, distribution, and destruction workflows
- Version-controlled certificate templates with algorithm and validity policy
- Security-related issue management via structured audit exports
- Patch and firmware delivery tracked by cryptographic manifest
Component Requirements from SL1 to SL4
The technical standard for components: Component Requirements CR 1.1 through 7.6 across seven Foundational Requirement families. TigerTrust maps directly to the CLM-relevant subset.
- CR 1.1 — Human user identification and authentication via PKI
- CR 1.2 — Device identification via TPM 2.0 / 802.1AR DevID
- CR 1.5 — Authenticator management with TPM-resident keys
- CR 3.1 — Communication integrity via mTLS with short-lived certs
From field devices to enterprise DMZ
A typical IEC 62443-aligned deployment spans Purdue Levels 0-5. TigerTrust runs at Level 4-5 as the credential authority; agents run at every lower level, handling attestation and issuance locally.
- Level 0-1 field devices with TPM 2.0 and IDevID
- Level 2 PLCs / HMIs with attested certificates for engineering-station mTLS
- Level 3 SCADA and historians with zone-and-conduit certificate segmentation
- Level 4-5 PKI Core with PKCS#11 HSM and SIEM audit export
What TigerTrust does, what your team owns
IEC 62443 certification is issued to a specific system deployment or component product — never to a piece of software in isolation. TigerTrust automates the credential controls; your team owns the system-level compliance work.
- TigerTrust automates CR 1.2, CR 1.5, CR 3.3, CR 3.5 evidence
- Your team owns SL-T target selection and zone-and-conduit design
- Your team owns golden PCR baseline capture and change control
- Your team engages the certification body (TUV, exida, ISASecure)
The IEC 62443 credential controls, automated.
Every CLM-relevant Component Requirement backed by a specific TigerTrust capability — not a mapping in a spreadsheet.
- UEFI event log replay
- SHA-256 and SHA-384 banks
- Structured failure codes for SIEM
- TPM2_Certify proves residency
- Thales / Entrust / AWS CloudHSM
- YubiHSM 2 for smaller deployments
- Per-zone certificate templates
- Automated rotation on drift
- mTLS enforcement
Control mapping: IEC 62443-4-2 to TigerTrust
Six of the most CLM-relevant Component Requirements from IEC 62443-4-2, mapped to the specific TigerTrust capability that satisfies each.
| Component Requirement | Requirement | TigerTrust Capability |
|---|---|---|
| CR 1.1 | Human user identification and authentication | Certificate-based user identity via PKI, role-based access control, and full audit trail of every issuance action. |
| CR 1.2 | Software process and device identification and authentication | TPM 2.0 attestation binds device identity to specific silicon (EK + AK via Credential Activation). IEEE 802.1AR IDevID / LDevID issuance built in. |
| CR 1.5 | Authenticator management (including cryptographic keys) | Automated certificate lifecycle from issuance to revocation. TPM-resident private keys never leave hardware. PKCS#11 HSM for CA private keys. |
| CR 3.1 | Communication integrity | mTLS enforcement on device-to-server links; short-lived TPM-attested certificates with automated renewal; multi-bank SHA-256 / SHA-384 attestation. |
| CR 3.3 | Security functionality verification | PCR-gated issuance verifies Secure Boot state (PCR7), firmware measurements (PCR0-3), and boot loader / kernel integrity via UEFI event log replay. |
| CR 3.5 | Protection of audit information | Every attestation attempt (pass or fail) recorded with atomic-consumption nonces. Runtime re-attestation worker records audit events on every sweep. |