AI基礎設施採用硬體認證憑證的必要性

Why Hardware-Attested Credentials for AI Infrastructure

Jan 20, 2026
• Beyond Identity

When a GPU training server gets compromised, the first question is always: what credentials were on that box, and where could they go? SSH keys scattered across hundreds of nodes. Service accounts with static secrets. Nobody knows exactly what exists on which machines.

Hardware-attested credentials eliminate this question. Credentials bound to verified hardware cannot be extracted or moved. The trust anchor is silicon, not software.

Why Do Traditional Approaches Fail?

Traditional credential distribution has three fatal flaws: no hardware binding, no attestation gate, and no visibility.

No hardware binding. Credentials work anywhere. Copy an SSH key to your laptop, it works from your laptop. Exfiltrate a service account token, it works from attacker infrastructure. The credential has no memory of where it belongs.

No attestation gate. Credentials get distributed regardless of target system state. Compromised kernel? Modified firmware? Tampered OS image? Traditional distribution doesn’t ask. The credential flows, and you hope for the best.

No visibility. When incidents occur, you need to know what credentials existed on the compromised system. But credential inventories are incomplete. SSH keys get added and never removed. Service accounts get created for one-off tasks and forgotten.

Identity solutions like MFA, SSO, and certificate-based access verify the user. They don’t verify the target system. If a server has a kernel-level rootkit, your identity platform has no way to know. Your credentials work. The rootkit captures everything.

Modern rootkits using io_uring operate entirely outside the syscall layer, invisible to host-based security tools. Software-based security cannot verify the platform it runs on. You cannot trust a host to report its own compromise.

How Does Hardware Attestation Change This?

Hardware attestation inverts the trust model. Verify host integrity before any credential reaches it. Credentials only flow to infrastructure that proves it hasn’t been tampered with.

NVIDIA BlueField DPUs implement DICE and SPDM for cryptographic attestation. The DPU proves its identity and reports firmware and software measurements, signed by hardware-protected keys.

Verify before distributing. Query attestation state before any credential reaches a node. Only after verification passes does the credential flow.

Bind credentials to hardware. Private keys live in DPU hardware security modules. They sign operations but cannot be read out. Even root on the host cannot extract them.

Enforce below the OS. The DPU sits between network and host, enforcing policy before traffic reaches the host CPU. A compromised kernel cannot bypass DPU-layer controls.

The DPU runs independently with its own CPU, memory, and firmware. Security agents on the DPU operate in a separate trust domain. A rootkit on the host cannot tamper with code running on the DPU.

How Does This Change Incident Response?

Traditional: Incident response starts with questions. What credentials were on that system? Which service accounts had access? You rotate secrets fleet-wide because you can’t be certain what was exposed. Every system sharing credentials with the compromised host is potentially affected.

Hardware-attested: Credentials on that host were bound to that host’s hardware. They cannot be extracted or used from another system. New credential distribution stopped when attestation failed. Blast radius is contained to that specific host during the compromise window. No credential rotation fire drill.

GPU clusters hold model weights worth hundreds of millions. Training runs process proprietary data. When incidents happen, the difference between “rotate everything” and “contained to one host” is the difference between a fire drill and a measured response.

Secure Infrastructure binds credentials to hardware so they can’t be extracted, even by root. See the quickstart guide to try it.

Secure Infrastructure Blog

Updates and announcements from the Secure Infrastructure project