Notifications
Clear all
Topic starter
02/08/2026 12:20 pm
TL;DR: Infrastructure and CI/CD systems gained workload identity federation, reducing reliance on long-lived API keys, auth keys, and OAuth clients while also introducing services, peer relays, multiple tailnets, and app capabilities, according to Tailscale. The governance shift is bigger than connectivity: it pushes NHI management toward federation, scoped access, and shorter-lived trust.
NHIMG editorial — based on content published by Tailscale: a recap of Fall Update Week and its new connectivity and identity features
Questions worth separating out
Q: How should security teams replace long-lived NHI credentials in CI and automation?
A: Use workload identity federation wherever the platform supports it, then reserve reusable auth keys for narrow, one-time cases only.
Q: Why do federated NHI controls reduce risk more effectively than static API keys?
A: Federated controls reduce the window in which a credential can be stolen and reused, and they tie access to a live trust relationship instead of a durable secret.
Q: What do security teams get wrong about machine identity management?
A: Security teams often treat certificates, keys, and tokens as infrastructure details instead of governed identities.
Practitioner guidance
- Map every long-lived NHI credential to a federation path Start with infrastructure systems and CI/CD pipelines still using API keys, auth keys, or OAuth clients.
- Rebuild access reviews around services, not just machines If a defined resource can move independently of a host, then entitlement reviews need to follow the service lifecycle.
- Define governance for each tailnet as a separate control domain Assign an owner, review cadence, and offboarding process to every tailnet, including API-created environments.
What's in the full article
Tailscale's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific implementation notes for workload identity federation across infrastructure and CI/CD systems.
- Feature-level detail on services, peer relays, and multiple tailnets for teams evaluating rollout paths.
- App capability behaviour and HTTP header propagation details for developers integrating identity into applications.
- The webinar and product demos that show the new features in context.
Workload identity federation: what it means for NHI key management?
Explore further
02/08/2026 1:20 pm
Workload identity federation is the cleaner answer to credential persistence, not a generic zero-trust slogan. The value is that infrastructure and CI/CD systems can authenticate without carrying long-lived API keys, auth keys, or OAuth clients. That reduces the standing secret problem that keeps showing up in NHI incidents, where the credential outlives the workflow that was meant to use it. Practitioners should read this as a shift from secret custody to trust policy design.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do organisations govern multiple tailnets without creating identity sprawl?
A: Define each tailnet as its own governed environment with clear ownership, review cadence, and offboarding criteria. Then standardise the identity provider, access policy patterns, and exception handling across all of them. Without that discipline, segmentation can hide privilege creep instead of reducing it.
👉 Read our full editorial: Tailscale's workload identity federation shifts NHI key management
