Electronics Guide

Secure Element Architecture

Secure elements are purpose-built integrated circuits designed to store cryptographic keys and perform cryptographic operations in a protected environment. These chips implement multiple layers of protection including encrypted memory, active tamper detection, environmental sensors, and shielded data paths that resist side-channel analysis. The security architecture ensures that private keys cannot be extracted through software interfaces, physical probing, or power analysis attacks.

Key generation occurs within the secure element using on-chip true random number generators, ensuring that private keys never exist outside the protected environment. Cryptographic operations including signing and decryption execute within the secure element, with only results exported to the host system. This architecture means that even if the host system is completely compromised, the attacker cannot extract private keys or perform operations without physical possession of the hardware token.

Key Storage Organization

Hardware tokens organize cryptographic materials into separate storage areas or key slots. Each slot typically holds a certificate, its corresponding private key, and associated metadata. Different slots may serve different purposes: authentication keys for login, signing keys for digital signatures, encryption keys for data protection, and card authentication keys for device-level operations. Access control policies can require different PINs or authorization for different key slots.

Key hierarchy within hardware tokens often includes a master key that encrypts stored credentials, device keys that enable secure communication with the token, and user keys for authentication and cryptographic operations. Administrative keys enable token management operations including PIN reset and certificate loading. Proper key hierarchy design ensures that compromise of one key does not enable access to others.

Tamper Protection

Physical tamper protection prevents attacks that attempt to extract keys through direct access to the secure element. Active mesh layers detect attempts to probe internal circuits, triggering key erasure before extraction can succeed. Environmental sensors detect conditions outside normal operating parameters that might indicate attack attempts, including voltage glitching, temperature extremes, or light exposure from decapsulation attacks.

Tamper-evident packaging provides visual indication if physical attacks have been attempted. Potted assemblies and destroyed-on-removal designs make covert tampering difficult. For high-security applications, hardware tokens may carry FIPS 140-3 Level 3 or Level 4 certification, demonstrating resistance to physical attacks through standardized evaluation procedures. FIPS 140-3 (which incorporates ISO/IEC 19790 and ISO/IEC 24759) superseded FIPS 140-2 for new validations; the Cryptographic Module Validation Program began accepting FIPS 140-3 submissions in 2020 and moves all remaining FIPS 140-2 certificates to the historical list on September 21, 2026. Historical status is a procurement signal rather than a revocation: federal agencies should not specify those modules in new acquisitions, but existing deployments may continue to operate.

Common Criteria evaluation provides a complementary assurance path. Smart card integrated circuits and card operating systems are commonly certified against a smart card protection profile at EAL5+ or EAL6+, with the augmentation covering resistance to high-attack-potential vulnerability analysis. A FIPS validation and a Common Criteria certificate answer different questions, and buyers for regulated environments frequently require both. In practice most commercial authentication tokens target Level 3, where tamper response and identity-based operator authentication are required; Level 4 modules are rare and largely confined to specialized HSM products. The level of tamper protection should match the threat model and value of the protected credentials.

Token Architecture

USB tokens contain a secure element connected to a USB controller that implements standard device classes for communication with host systems. The USB interface typically presents the token as a CCID (Chip Card Interface Device) smart card reader with an integrated card, enabling compatibility with standard smart card middleware. Some tokens additionally implement HID (Human Interface Device) keyboard emulation for entering one-time passwords or triggering authentication actions.

Internal flash memory may store applications, certificates, or configuration data that does not require secure element protection. The secure element handles all cryptographic operations and key storage. Communication between the USB controller and secure element uses encrypted and authenticated channels to prevent attacks that attempt to intercept or modify commands and responses.

PKCS#11 and Cryptographic APIs

PKCS#11 (Cryptoki) defines a standard API for applications to access cryptographic tokens. This platform-independent interface enables applications to use certificates and keys stored in hardware tokens without needing token-specific code. PKCS#11 libraries provided by token vendors translate API calls into device-specific commands, presenting a uniform interface regardless of the underlying hardware. The application opens a session with a token slot, authenticates with a user PIN, locates key and certificate objects by attribute, and then calls sign or decrypt operations that execute inside the device.

Maintenance of the specification moved from RSA Laboratories to the OASIS PKCS 11 Technical Committee, which published version 2.40 in 2015 and version 3.0 in 2020. Version 3.2 was approved as an OASIS Standard in July 2026, adding mechanisms for the NIST post-quantum algorithms ML-KEM, ML-DSA, and SLH-DSA alongside extended vendor-extension and combined-operation support. Deployed middleware often lags the specification, so integration work must account for the version a given token library actually implements rather than the newest published revision.

Microsoft CryptoAPI and its successor Cryptography API: Next Generation (CNG) provide Windows-native interfaces to cryptographic hardware. Token vendors supply minidriver or Key Storage Provider (KSP) implementations that integrate with Windows certificate stores and security subsystems. macOS uses the CryptoTokenKit framework for smart card integration. These platform-specific APIs enable certificate-based authentication in web browsers, VPN clients, email applications, and operating system login.

FIDO and WebAuthn Integration

Modern USB tokens increasingly support FIDO2/WebAuthn protocols alongside traditional certificate authentication. FIDO2 combines two specifications: the W3C Web Authentication (WebAuthn) API that browsers expose to web applications, and the FIDO Alliance Client to Authenticator Protocol (CTAP2) that carries requests to an external authenticator over USB HID, NFC, or Bluetooth Low Energy. This enables passwordless authentication to web applications using the same hardware token that provides certificate-based VPN access. FIDO protocols use challenge-response authentication with device-generated key pairs, and the browser binds each assertion to the requesting origin, so a credential registered for one domain cannot be replayed to a look-alike phishing site.

The two models make different trade-offs. FIDO credentials are self-generated per relying party and carry no certificate authority, no naming, and no revocation infrastructure, which removes most of the administrative cost of PKI but also removes the ability to assert a verified organizational identity or to revoke a credential centrally. Certificates carry that identity and revocation machinery at the price of enrollment, chain validation, and lifecycle management. Hybrid tokens that support both PKCS#11 certificate operations and FIDO2 authentication allow each application to use the method that suits it. Enterprise deployments commonly retain certificates for VPN, smart card logon, and document signing while deploying FIDO2 for modern web applications, with the shared hardware reducing the number of authenticators users must carry.

Card Operating Systems

Smart card operating systems manage the secure element's resources, implement cryptographic operations, and enforce access control policies. Java Card enables development of card applications (applets) in a subset of Java, providing portability across card platforms. MULTOS provides another multi-application card platform with strong security guarantees. Proprietary operating systems from major card vendors offer optimized performance and specialized features.

Card applications implement specific functionality including certificate storage, authentication protocols, and digital signature operations. Multiple applications can coexist on a single card, enabling one card to serve authentication, physical access control, and payment functions. Application isolation ensures that security vulnerabilities in one application cannot compromise others.

Contact Interface Communication

Contact smart cards communicate through the ISO/IEC 7816 protocol family. ISO/IEC 7816-2 fixes the dimensions and location of the contacts on the card body. ISO/IEC 7816-3 defines the electrical interface and transmission protocols: the card declares its capabilities in an answer-to-reset sequence after power-up, then communicates using either the asynchronous character protocol T=0 or the block protocol T=1. The same part defines the supply voltage classes, class A at 5 V, class B at 3 V, and class C at 1.8 V, with modern cards typically supporting the lower classes for reduced power draw. ISO/IEC 7816-4 specifies Application Protocol Data Units (APDUs), the command and response structures that carry select, verify, and cryptographic operations between reader and card, along with the file and object organization those commands address.

Card readers provide the physical interface to host systems, supplying power to cards and managing communication timing. USB readers present cards as CCID devices for direct communication. PC/SC (Personal Computer/Smart Card) middleware provides a standardized API for applications to communicate with cards through readers. Reader selection and configuration can affect authentication reliability and user experience.

Contactless Communication

Contactless smart cards communicate wirelessly at 13.56 MHz. ISO/IEC 14443 defines proximity cards, the class used for credential applications: Type A and Type B differ in modulation and anticollision but share the carrier frequency and an operating range of a few centimeters, with data rates from 106 kbit/s up to 848 kbit/s in the higher bit-rate modes. ISO/IEC 15693 defines vicinity cards that trade data rate for a working range on the order of a meter, which suits inventory and asset tagging rather than authentication, where short range is a deliberate security property. Power is harvested from the reader's electromagnetic field, enabling battery-free operation, though the available power budget constrains how much public key computation a contactless card can perform within an acceptable transaction time.

The speed of contactless communication enables rapid authentication suitable for high-throughput applications like transit systems and building access. However, contactless communication also creates security considerations including relay attacks where attackers extend the communication range between card and reader. Distance bounding protocols and reader authentication help mitigate these risks in security-sensitive applications.

PIV Card Architecture

PIV cards contain multiple certificates for different purposes: a PIV Authentication certificate for general authentication, a Digital Signature certificate for document signing, a Key Management certificate for encryption key establishment, and a Card Authentication certificate for contactless building access. Each certificate has a corresponding private key protected by the card's secure element. Biometric data including fingerprint templates may also be stored for verification.

The PIV application implements specific APDU commands for authentication, signature generation, and key management operations. Authentication mechanisms include single-factor using the card, dual-factor using the card plus PIN, and three-factor adding biometric verification. The PIV Authentication certificate provides the primary identity assertion for network authentication and logical access control.

The supporting NIST special publications carry the technical detail. SP 800-73-5, released in July 2024, specifies the PIV interfaces in three parts covering the card application data model, the card edge command interface, and the client application programming interface; it also covers secure messaging and the virtual contact interface, which let a card expose PIN-protected data objects over the contactless interface through an authenticated, encrypted channel. SP 800-78-5, released alongside it, constrains the cryptographic algorithms and key sizes permitted on PIV credentials, retiring legacy options in favor of RSA 2048 and above and the NIST elliptic curves. Implementers should treat FIPS 201-3 as the policy layer and these publications as the normative interface and algorithm specifications.

Certificate Profiles

PIV certificate profiles specify the X.509 extensions and attributes required for each certificate type. The Subject Alternative Name (SAN) extension contains the principal name used for authentication, typically a User Principal Name (UPN) or email address that maps to directory entries. Key Usage extensions restrict certificate use to appropriate operations, preventing authentication certificates from being misused for digital signatures.

Federal PKI policies govern certificate issuance and management for PIV credentials. The Federal Bridge CA enables cross-certification with external PKIs while maintaining policy requirements. Certificate validation must verify the complete chain to a trusted root and confirm certificates have not been revoked. PIV-I (Interoperable) credentials extend PIV concepts to non-federal users who require access to federal systems.

Derived PIV Credentials

Derived credentials extend PIV authentication to mobile devices that cannot accommodate traditional smart card readers. The derived credential contains cryptographic keys bound to the PIV identity but stored on mobile devices using hardware-backed key storage. Credential derivation requires proof of possession of the original PIV card, establishing the binding between the derived credential and the verified PIV identity.

Mobile device secure enclaves including Apple Secure Enclave and Android hardware-backed keystore provide protection for derived credentials approaching that of dedicated smart cards. However, mobile devices face different threat models than smart cards, with considerations including device loss, malware, and physical compromise. Derived credential policies balance mobile access convenience against additional security risks.

Hardware Security Modules for PKI

Certificate Authority private keys require the strongest available protection, as compromise of a CA key enables an attacker to issue fraudulent certificates for any identity. Hardware Security Modules (HSMs) protect CA keys within FIPS 140-3 Level 3 or Level 4 certified boundaries, ensuring keys cannot be exported or extracted. CA signing operations occur within the HSM, with only signed certificates exported.

HSM partitions enable multiple CAs to share physical HSM infrastructure while maintaining cryptographic separation. Role-based access controls ensure that certificate issuance requires proper authorization. Audit logging creates tamper-evident records of all operations. HSM clustering provides high availability and enables geographic distribution of CA infrastructure while maintaining consistent key protection.

Registration Authority Systems

Registration Authorities (RAs) verify identity before certificate issuance, implementing the policies that determine what evidence is required for different certificate types. RA hardware may include identity proofing equipment such as document scanners and fingerprint readers. Secure communication with Certificate Authorities ensures that certificate requests cannot be modified in transit.

Automated enrollment systems streamline certificate issuance for enterprise users. Integration with directory services enables automatic certificate provisioning when accounts are created. Mobile Device Management (MDM) integration pushes certificates to managed devices. Self-service portals enable users to request and renew certificates within policy constraints. Proper RA infrastructure balances security requirements against operational efficiency.

Key Escrow and Recovery

Encryption key escrow enables recovery of encrypted data when users lose access to their private keys. Key escrow systems must protect escrowed keys from unauthorized access while enabling legitimate recovery operations. HSM-based escrow storage ensures escrowed keys receive the same protection as active keys. Multi-party recovery procedures require multiple authorized individuals to approve key recovery, preventing abuse.

Hardware key recovery appliances automate the recovery process while maintaining security controls. Integration with help desk systems enables authorized personnel to initiate recovery requests. Audit trails document all recovery operations for compliance and investigation purposes. Proper key escrow balances data recovery requirements against the risks of enabling unauthorized access to encrypted data.

TLS Client Authentication

Transport Layer Security client authentication requests that clients present certificates during the TLS handshake. The server sends a CertificateRequest message listing acceptable CAs, and the client responds with a certificate chain and proof of private key possession through a CertificateVerify message. This mutual authentication establishes the client identity at the session layer, enabling all application traffic over the connection to be attributed to the authenticated user.

TLS 1.3 changed the mechanics in ways that matter for deployment. The client certificate and CertificateVerify message are now sent inside the encrypted portion of the handshake rather than in the clear, so a passive observer can no longer harvest client identities from the wire. TLS 1.3 also removed renegotiation and replaced it with post-handshake authentication, which lets a server request a client certificate after the connection is established, for example when a request reaches a protected resource. Applications that previously triggered a certificate prompt through renegotiation must be reworked, and both client and server must have opted into post-handshake authentication during the initial handshake.

Hardware tokens integrate with TLS through PKCS#11 or platform cryptographic APIs. The TLS library delegates private key operations to the token, which signs the handshake transcript to prove key possession. The certificate remains in the token or is cached on the host system. Because each handshake requires a token signature, connection-heavy workloads are bounded by token throughput, which is typically a few operations per second on a smart card rather than the thousands per second a software key would allow; session resumption and connection reuse are therefore important tuning levers. Proper certificate chain configuration ensures servers can validate client certificates back to trusted roots.

Kerberos PKINIT

PKINIT extends Kerberos authentication to use public key cryptography for initial authentication. Instead of proving knowledge of a password-derived key, the client presents a certificate and signs authentication data with the corresponding private key. The Key Distribution Center (KDC) validates the certificate and issues a Ticket Granting Ticket (TGT) that enables subsequent Kerberos authentication to network services.

Windows Smart Card Logon uses PKINIT to enable certificate-based domain authentication. Users insert their smart card or USB token and enter a PIN rather than a password. The domain controller validates the certificate and maps it to a directory account. This integration enables certificate-based authentication to provide single sign-on to all Kerberos-enabled services.

How that mapping is performed became a significant operational issue. Historically domain controllers matched certificates to accounts on the User Principal Name in the Subject Alternative Name, a field an attacker who could influence enrollment might be able to set to another user's value. Microsoft addressed this in the May 2022 update documented as KB5014754, which introduced strong certificate mapping through a security identifier (SID) extension embedded in the certificate by the issuing CA, tying a certificate to exactly one account. Domain controllers moved to full enforcement with the February 2025 security update, and the registry setting that allowed a fallback to compatibility mode stopped being honored after the September 2025 update. Organizations running smart card logon, 802.1X, or certificate-based VPN against Active Directory must ensure their certificate templates issue the SID extension or configure an explicit strong mapping, because weakly mapped certificates are now rejected outright.

SAML and OAuth Integration

Certificate-based authentication can serve as the authentication method for SAML Identity Providers, enabling single sign-on to cloud applications. Users authenticate to the IdP using their hardware tokens, and the IdP generates SAML assertions that grant access to relying party applications. This architecture extends certificate authentication to applications that cannot directly integrate with PKI.

OAuth 2.0 client credential flows can use certificate-based client authentication, with the client presenting its certificate during token requests. JSON Web Tokens (JWTs) can be signed using hardware-protected private keys, enabling certificate-backed bearer tokens for API authentication. These integrations enable hardware-protected credentials to secure modern application architectures.

Enrollment and Provisioning

Certificate enrollment begins with identity verification appropriate to the certificate assurance level. In-person enrollment with identity document verification provides the highest assurance. Remote enrollment may rely on existing identity verification such as employment records. The enrollment process must bind the verified identity to the cryptographic key pair, typically by generating keys on the hardware token during enrollment.

Token provisioning includes key generation, certificate request creation, certificate loading, and PIN initialization. Secure provisioning processes ensure tokens are not compromised before reaching users. Distribution mechanisms must verify recipient identity and maintain chain of custody. Initial PIN delivery through separate channels prevents token use by interceptors.

Key attestation strengthens the enrollment step. Many tokens can produce an attestation statement, signed by a factory-provisioned key whose certificate chains to the manufacturer, asserting that a given key pair was generated inside the device, is marked non-exportable, and is protected by a stated PIN or touch policy. A certificate authority that validates the attestation before issuing gains cryptographic evidence that the subscriber's private key really is in hardware, rather than relying on procedure alone. This closes a gap that ordinary certificate signing requests cannot address, since a request proves possession of a private key but says nothing about where that key lives.

Reader and Middleware Deployment

Smart card deployments require reader hardware at each authentication point. Reader selection considers form factor (internal, external, keyboard-integrated), interface (USB, built-in), and compatibility with deployed card types. Driver installation and configuration may require administrative privileges and management tool deployment.

Middleware installation enables applications to communicate with hardware tokens through standard APIs. Platform-native middleware (Windows Smart Card subsystem, macOS CryptoTokenKit) may provide base functionality, with vendor middleware adding token-specific features. Middleware configuration specifies certificate mappings, PIN caching policies, and reader preferences. Enterprise deployment tools can automate middleware installation and configuration.

Certificate Lifecycle Management

Certificates have limited validity periods, commonly one to three years for enterprise client credentials, requiring renewal before expiration to maintain authentication capability. Credentials on a physical card are additionally bound by the card itself: a certificate should never be issued to expire after the card that carries it, and cards have their own service life driven by chip obsolescence, contact wear, and printed-credential policy. Renewal processes should begin well before expiration to allow time for resolution of any issues, and renewal on a hardware token normally means generating a fresh key pair on the device rather than recertifying the old key, since the point of hardware protection is lost if key material is carried forward indefinitely. Automated renewal systems reduce administrative burden and prevent authentication outages from expired certificates.

Revocation procedures must be established for lost tokens, terminated employees, and key compromise. Certificate Revocation Lists must be published promptly and accessible to all relying parties. OCSP responders provide real-time revocation status but require high availability. Client certificate revocation carries a structural weakness that server certificate revocation does not: OCSP stapling lets a server attach a fresh status response to its own certificate, but there is no equivalent path for a client, so the verifier must reach the CRL distribution point or OCSP responder itself. Revocation checking configuration must therefore decide explicitly what happens when that lookup fails. Fail-open preserves availability but silently accepts revoked credentials during an outage; fail-closed preserves security but converts a responder failure into an authentication outage. High-assurance environments generally choose fail-closed for the credentials that matter most and invest in responder redundancy and cached CRLs to make that choice survivable.

User Training and Support

Users need training on proper token handling, PIN management, and authentication procedures. Training should cover what to do if tokens are lost or stolen, how to recognize authentication failures, and when to contact support. Clear documentation reduces support burden and improves security by ensuring users follow proper procedures.

Help desk procedures must address common issues including forgotten PINs, locked tokens, and certificate expiration. PIN reset procedures should verify user identity through alternative means before resetting. Token replacement processes should revoke old certificates before issuing new credentials. Escalation paths should be defined for unusual situations requiring security team involvement.

Protection Against Common Attacks

Hardware-protected certificates resist password attacks including guessing, brute force, credential stuffing, and dictionary attacks. Phishing attacks that capture credentials are defeated because the private key never leaves the token and cannot be transmitted to attackers. Malware that steals credentials from disk or memory cannot extract keys from hardware tokens. These protections address the most common authentication attack vectors.

Replay attacks are prevented by cryptographic protocols that use nonces or timestamps to ensure each authentication is unique. Man-in-the-middle attacks are detected through server certificate validation in TLS and Kerberos. The binding between the certificate and the protected private key ensures that stolen certificates alone cannot enable authentication.

Residual Risks

Physical token theft combined with PIN compromise enables unauthorized authentication until the token is revoked. PIN protection measures including lockout after failed attempts and secure PIN entry limit this risk. Shoulder surfing and PIN capture through malware remain concerns that proper user training and secure entry mechanisms can mitigate.

Compromised endpoints can abuse authenticated sessions even without extracting credentials. Session hijacking after successful authentication, fraudulent transaction injection, and screen capture attacks target the authenticated session rather than the credential itself. Endpoint security measures complement authentication security to address these risks.

Side-channel attacks against hardware tokens remain a concern for high-value targets. While certified tokens resist documented attacks, new attack techniques continually emerge. High-assurance applications should consider tokens with current certifications and monitor security research for newly discovered vulnerabilities.

Certificate Authority Compromise

The security of certificate-based authentication ultimately depends on CA integrity. A compromised CA can issue fraudulent certificates for any identity within its scope, and relying parties will accept them because the signature chain validates correctly. HSM protection, multi-party controls, and comprehensive auditing reduce the risk of key compromise. Keeping the root CA offline and issuing only through intermediate CAs limits exposure, and name constraints on subordinate CA certificates bound what a compromised intermediate can assert.

Detection controls matter as much as prevention, because a fraudulent certificate issued by a trusted CA is otherwise indistinguishable from a legitimate one. Certificate Transparency logs provide public, append-only records that make unauthorized issuance detectable, though the mechanism applies to publicly trusted TLS certificates rather than to private enterprise or federal PKI. Internal PKI must supply the equivalent through issuance auditing, reconciliation of issued certificates against the authoritative identity source, and alerting on issuance outside expected templates and hours. Compromise of an authentication CA is also more damaging than compromise of a single user token, since revocation requires distrusting an entire branch of the hierarchy and reissuing every credential beneath it. Rehearsed CA compromise and recovery procedures are part of a defensible deployment.

Post-Quantum Cryptography

Current certificate-based authentication relies on RSA and elliptic curve cryptography that a sufficiently capable quantum computer could break using Shor's algorithm. In August 2024 NIST published its first post-quantum standards: FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for key encapsulation, FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) for digital signatures, and FIPS 205 (SLH-DSA, derived from SPHINCS+) for stateless hash-based signatures. NIST selected a fifth algorithm, the code-based key encapsulation mechanism HQC, in March 2025 to provide a backup that does not rest on structured lattices, and a signature scheme derived from Falcon is progressing through public draft as FIPS 206. These algorithms must now be implemented in cryptographic tokens and HSMs, often alongside classical algorithms in hybrid constructions during the transition.

Size is the practical obstacle for hardware credentials. An ECDSA P-256 public key occupies 64 bytes and its signature roughly 64 bytes, whereas ML-DSA-65 uses a 1,952-byte public key and produces a 3,309-byte signature. SLH-DSA signatures are larger still, running to several kilobytes depending on parameter set. Smart cards with tens of kilobytes of usable secure storage and constrained transmission buffers cannot simply substitute the new algorithms for the old ones. Migration therefore requires planning for algorithm agility, adequate token storage and APDU chaining, higher on-card computation time, and reissuance of certificates and trust anchors. Because credentials issued today may still be in service when cryptographically relevant quantum computers arrive, procurement for long-lived deployments should favor tokens whose firmware can be updated to add post-quantum algorithms.

Passwordless Authentication

The industry trend toward passwordless authentication positions hardware-backed credentials as the primary authentication factor rather than a second factor supplementing passwords. FIDO2/WebAuthn protocols enable passwordless authentication with strong hardware protection. Certificate-based authentication is evolving to support these passwordless scenarios while maintaining enterprise PKI investments.

Decentralized Identity

Decentralized identity frameworks enable user-controlled credentials that do not depend on a single centralized identity provider at the point of use. The W3C Decentralized Identifiers and Verifiable Credentials specifications describe identifiers a subject controls through a private key and signed credential objects that a holder can present selectively to a verifier. The underlying cryptography is the same asymmetric signing that certificates use, so the hardware requirement is unchanged: the controlling private key must be generated and held in a secure element if the credential is to resist copying.

Related work is already reaching deployment in digital identity documents. The ISO/IEC 18013-5 mobile driving license specification defines a device-retained credential presented over NFC or Bluetooth with keys held in the phone's secure hardware, and it is the model that several jurisdictions have adopted for mobile identity. Whether these frameworks displace certificate hierarchies or simply layer on top of them remains unsettled, but the hardware protecting the keys, and the attestation proving those keys are in hardware, carry over directly from established certificate practice.