A full elimination effort usually fails if organisations ignore older platforms and external integrations that still depend on traditional secrets. Those dependencies can block migration, create workarounds, or push teams back toward insecure exceptions. A practical programme keeps managed identities as the default while maintaining controlled secret management only where the environment truly requires it.
Why Legacy and Third-Party Dependence Breaks “No Secrets” Programmes
Trying to remove secrets everywhere sounds clean, but legacy platforms and external APIs often still rely on static credentials, shared tokens, or API keys. If teams ignore those dependencies, migration stalls and people create bypasses to keep business services running. The result is usually not better security, but a messier control model with exceptions that are harder to govern and rotate.
That failure is especially common when the programme assumes every system can support managed identities on the same timeline. In reality, older middleware, vendor integrations, batch jobs, and partner APIs may have fixed authentication patterns that cannot be changed quickly. A useful reference point is the OWASP OWASP Non-Human Identity Top 10, which helps teams think about machine access, credential sprawl, and the control gaps that appear when access is distributed across many systems.
In practice, teams usually discover the weakest dependency only after a migration breaks a production integration or a vendor insists on a secret-based workaround.
How It Works in Practice
The practical problem is not the goal, it is the sequencing. A sensible programme treats managed identities as the default target state, but it first inventories where secrets are still functionally required. That inventory has to include old applications, ETL jobs, partner APIs, scripts, and embedded devices, not just modern cloud services.
- Classify each dependency by whether it can support federated auth, short-lived credentials, or only static secrets.
- Separate internal systems from third-party services, because the migration path and ownership model are different.
- Allow controlled exceptions where a secret is still unavoidable, but keep the exception scoped, documented, and reviewable.
- Design rotation, storage, and revocation around the systems that cannot yet move, instead of pretending they do not exist.
The main operational mistake is to start with a blanket ban and assume remediation will follow automatically. That often pushes engineers toward hardcoded credentials, copied tokens, or ad hoc vault usage that bypasses the intended control path. A more sustainable approach is to reduce secret use where the platform supports it, while keeping secrets tightly governed where technical or contractual constraints remain.
GitGuardian’s The State of Secrets Sprawl 2026 found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is a strong reminder that detection without revocation and transition planning leaves old exposure in place.
These controls tend to break down in hybrid estates with long-lived vendor integrations, because the exception handling becomes the real production path.
Common Variations and Edge Cases
Tighter secret elimination often increases operational friction, so teams have to balance standardisation against service continuity. The right answer depends on whether the dependency is truly temporary, permanently constrained, or contractually fixed by a third party.
Some edge cases deserve different treatment:
- Legacy batch processes may need secrets for a defined period, but should be isolated and rotated aggressively.
- Third-party APIs may support OAuth or federated flows only partially, forcing a split model across vendors.
- Air-gapped or offline systems may never support managed identities in the usual sense, so governance matters more than purity.
There is no universal standard for complete secret removal across all environments. Best practice is to make exceptions explicit and time-bound, then revisit them as platforms and vendors modernise. If a team cannot explain why a secret still exists, who owns it, and what would break if it were removed, the programme has probably drifted from design into convenience.
NHIMG research on secrets and NHI exposure shows why that drift matters: duplicated credentials, overused identities, and exposed tokens turn one exception into many downstream risks. The key is to prevent exception creep from becoming the new normal.
Risk and Threat Considerations
The material risk is control regression. When organisations try to remove secrets faster than their legacy estate and external integrations can support, they often reintroduce weaker authentication paths, broaden privilege, or leave unmanaged exceptions in place.
Failure mechanism: A secret-free target state collides with systems that cannot federate, cannot rotate cleanly, or cannot be modified quickly. Teams then preserve service continuity with shared tokens, copied credentials, or hidden bypass accounts, which weakens visibility and makes revocation harder.
Impact: Exposure becomes harder to detect, compromise becomes easier to scale across integrations, and incident response slows because ownership, rotation, and blast radius are no longer clear.
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 address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Covers machine access and secret sprawl in legacy and third-party integrations. |
| NHI-03 — Access Governance and Lifecycle | Applies to retaining controlled access where systems cannot yet move off secrets. | |
| Recommendation — Inventory non-human secrets, scope exceptions, and rotate or revoke credentials on a defined schedule. Define owners, review dates, and retirement criteria for every remaining credential path. | ||
| CIS Controls v8 | 6.3 — Account Monitoring and Control | Supports tracking and removing unnecessary credentials and stale access paths. |
| Recommendation — Review and remove stale accounts, keys, and tokens that keep legacy integrations alive. | ||
Practitioner Guidance
What to prioritise: Build the migration plan around dependency truth, not architecture preference. The first question is which systems can move to managed identities now, which can move later, and which require a governed secret for the foreseeable future.
Decision rule: If removing a secret would break a legacy platform or third-party API today, treat that as a controlled exception and focus on reducing exposure, scoping access, and defining a retirement path rather than forcing an immediate ban.
What to verify: Each remaining secret should have an owner, a reason it still exists, a rotation path, and a revocation trigger. If any of those are missing, the exception is already drifting into unmanaged risk.
What practitioners underestimate: The hardest part is usually not the migration target, but the long tail of vendors, scripts, and batch jobs that were never designed for modern identity flows. Those are the places where teams tend to fall back to convenience unless governance is explicit.
Practitioner takeaway: A successful programme does not remove every secret first, it removes avoidable secrets first and governs the unavoidable ones until the dependency can be retired.
Related resources from NHI Mgmt Group
- How should security teams govern third-party AI systems without losing visibility into provenance and model behaviour?
- How should security teams govern third-party app and GenAI access to core systems without creating blind spots?
- What happens when agencies try to run cloud and legacy systems without a shared identity layer?
- What happens when security teams try to handle incident response without orchestration across people and systems?
