Proving trust again after an event that made the previous proof stale: an update, a reboot, a lost state, an expired credential or a revocation.
Re-attestation is triggered by events. Typical triggers: a software or firmware update, lost local state, a credential that expired during downtime, a change of owner, or a revocation after a suspected compromise.
Its main jobs are recovery (a workload gets its identity back without a manual reset), operational efficiency (no hand-made join tokens or stale records to clean up) and compromise recovery (revoke, then force a clean, verified start).
A system without re-attestation has two bad options after such an event: trust the old proof, or wait for a person. Both fail at scale.
Example. A robot receives new firmware at night. In the morning the fleet system asks it to prove the new version before it assigns the first task.
Attested robotsAttested cloud workloads
Working on re-attestation for your product? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.