Notifications
Clear all
Topic starter
11/06/2026 11:57 pm
TL;DR: Kernel-anchored non-human identity depends on TLS building blocks such as certificates, key exchange, and signatures, and ECC delivered roughly 6.5x faster handshakes than RSA in its benchmark, according to Riptides. The deeper issue is that machine identity governance still hinges on trust establishment, not just encrypted transport.
NHIMG editorial — based on content published by Riptides: From Keys to Handshakes: How Cryptography Powers Riptides
By the numbers:
- ECC-384 provides better security than RSA-4096, as it is roughly equivalent to RSA-7680 in terms of cryptographic strength.
- A 256-bit ECC key is roughly equivalent to a 3072-bit RSA key.
Questions worth separating out
Q: How should security teams govern TLS-based workload identity at scale?
A: Security teams should assign clear ownership for certificate issuance, renewal, and revocation, then tie those processes to each workload class.
Q: When does ECC make sense for machine identity programmes?
A: ECC makes sense when handshake volume, CPU pressure, or connection churn makes RSA expensive at scale.
Q: What breaks when certificates are treated as static infrastructure artefacts?
A: What breaks is revocation discipline, ownership clarity, and the ability to respond when a workload changes or a key is exposed.
Practitioner guidance
- Map cryptographic trust to identity ownership Document which team owns certificate issuance, renewal, and revocation for each workload class, including services, jobs, and agents.
- Review handshake cost at service scale Measure TLS handshake volume and CPU overhead across high-churn services before standardising on a key type.
- Bind workload identity to verifiable trust bundles Use workload identity patterns that validate certificates against explicit trust bundles instead of implicit network trust.
What's in the full article
Riptides' full blog post covers the cryptographic mechanics this post intentionally leaves at a higher level:
- A step-by-step explanation of symmetric and asymmetric cryptography, including RSA, ECC, and key exchange mechanics
- Benchmark setup details for the TLS handshake test, including the local Linux environment and tool choice
- The raw RSA versus ECC comparison used in the handshake benchmark and the assumptions behind it
- The protocol-level breakdown of how certificates, signatures, and session keys interact during TLS
👉 Read Riptides' post on how cryptography powers kernel-level NHI identity →
Cryptographic handshakes for NHI identities: what changes for IAM teams?
Explore further
12/06/2026 8:53 am
Kernel-anchored identity collapses the distinction between transport security and machine identity governance. Once identity is enforced in the handshake path, the control point moves from perimeter policy to cryptographic proof. That shifts the governance burden to issuance, certificate trust, and workload attestation. Practitioners should treat this as an identity architecture decision, not a networking optimisation.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
A question worth separating out:
Q: How do workload identity controls support zero trust in practice?
A: They make each connection prove identity at the moment of access instead of relying on network placement or inherited trust. That is useful only when the identity is backed by strong issuance and lifecycle controls. For zero trust to work, the certificate and the workload must both be continuously governed.
👉 Read our full editorial: Kernel-level NHI identity depends on cryptographic handshakes
