Start by inventorying every credential class in use, including SaaS tokens, legacy secrets, CI/CD credentials, and any AI agent access paths. Then mark which systems can actually participate in SPIFFE attestation and which will need separate governance, so the rollout does not create an unmanaged residual estate.
How to scope the estate before you force SPIFFE everywhere
SPIFFE is strongest when the systems in scope can support workload identity, attestation, and short-lived credentials end to end. If you skip the inventory step, teams usually discover too late that some assets can use SPIFFE while others still depend on SaaS tokens, long-lived secrets, or ad hoc CI/CD credentials. The first job is therefore to map the estate by credential class, not by platform label.
That inventory should separate systems that can join the SPIFFE trust model from systems that cannot, because those two groups need different operating controls. In practice, the hard part is often not the SPIFFE-enabled path, but the unmanaged remainder, especially legacy apps, external integrations, and AI agent access paths that still need explicit governance.
A useful way to think about the first pass is: identify every place where an identity-bearing credential exists, then classify whether it is replaceable, bridgeable, or must remain separate. That avoids the common mistake of treating SPIFFE as a universal migration and leaving the residual estate with weaker visibility than before.
Which credentials usually create the residual estate?
The residual estate is usually made up of credentials that do not map cleanly to workload identity attestation. Common examples include SaaS API tokens, application secrets stored outside a vault, CI/CD deploy tokens, database passwords, legacy service accounts, and externally managed integrations. Those items are not just implementation detail, they define the boundary of what SPIFFE can and cannot safely absorb.
Separate governance matters because each credential class fails in a different way. SaaS tokens tend to persist across environments, legacy secrets are often hard to rotate, CI/CD credentials can spread through pipelines, and AI agent access paths may combine human approval with machine execution in ways that need explicit review. The first rollout decision is not how to migrate all of them, but which ones can be retired, which can be mediated, and which must remain on another control path.
For SPIFFE-specific grounding, the SPIFFE workload identity specification is the clean reference point for what SPIFFE is designed to standardise. For a broader rollout view, Guide to SPIFFE and SPIRE explains the attestation and trust-bundle model that makes the covered estate secure.
How should teams decide what gets SPIFFE and what gets separate governance?
The practical decision is to triage by attestation fit and operational blast radius. Systems that can present a stable workload identity, consume short-lived credentials, and participate in automated trust establishment are good SPIFFE candidates. Systems that depend on third-party SaaS auth, manual secret distribution, brittle legacy middleware, or cross-domain human approvals usually need a separate path until they can be refactored.
That triage should also tell you where governance must stay manual even if the credential is not. For example, a system may keep a legacy secret temporarily, but you still need ownership, rotation cadence, expiry tracking, and a clear decommission plan. The aim is not to bless exceptions indefinitely, but to prevent the residual estate from becoming an untracked shadow identity stack.
If the environment already contains container and Kubernetes workloads, the Kubernetes NHI Security Guide is useful because it shows where service accounts, projected tokens, RBAC, and workload identity interact with migration choices. For a broader identity lifecycle lens, Service Account Security Guide helps teams treat non-SPIFFE credentials as governed assets rather than temporary clutter.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | SPIFFE rollout scope depends on whether services and workloads can use attested identities. |
| IA-5 — Authenticator Management | The question centers on inventorying and governing tokens, secrets, and other credential classes. | |
| AC-2 — Account Management | Residual SaaS, legacy, and CI/CD access paths still need ownership and lifecycle control. | |
| Recommendation — Use IA-9 to govern service-to-service identities that can join the SPIFFE trust model. Apply IA-5 to inventory, rotate, and retire residual credentials outside SPIFFE. Use AC-2 to assign owners and lifecycle rules for non-SPIFFE access paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | The answer emphasizes discovering and governing every remaining credential class. |
| CIS-6 — Access Control Management | Separate governance is needed for systems that cannot be absorbed into SPIFFE. | |
| Recommendation — Use CIS-5 to inventory accounts, tokens, and service credentials before rollout. Use CIS-6 to constrain residual access paths that stay outside SPIFFE. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud estates often mix workload identity with tokens, secrets, and other residual credentials. |
| Recommendation — Map each workload and secret class to IAM ownership before migrating to SPIFFE. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Legacy secrets and tokens are a common residual estate when SPIFFE cannot cover everything. |
| NHI-01 — Improper Offboarding | The rollout can leave unmanaged residual access if non-SPIFFE credentials are not retired. | |
| NHI-05 — Overprivileged NHI | Residual credentials may keep excessive access if they are not separated and reviewed. | |
| Recommendation — Track and shorten any remaining long-lived secrets outside SPIFFE. Retire excluded credentials with explicit offboarding dates and owners. Reduce privileges on every credential class that remains outside SPIFFE. | ||
Practitioner Guidance
What to prioritise: inventory by credential class first, then by application. That order matters because the same application may hold multiple identity paths, and the rollback or replacement strategy often differs by credential type.
What to verify: every non-SPIFFE credential should have an owner, a purpose, a rotation or expiry rule, and a retirement decision. If you cannot state those four items, you do not have governance, you have exposure.
Decision rule: if a system cannot participate in attestation and short-lived identity issuance without custom handling, treat it as separate scope and control it explicitly rather than forcing a partial SPIFFE deployment.
Practitioner takeaway: the first rollout success criterion is not how much of the estate is on SPIFFE, but whether the remaining estate is fully visible, owned, and governed instead of being left behind as unmanaged credential debt.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams make access reviews cover the real application estate?
- How should security teams cover cloud workloads that EDR cannot reliably reach?
- What should teams do when a SaaS-first access tool does not cover regulated systems?