Treat the secret as a standing non-human privilege path and remove it from the pipeline as soon as a verifiable workload identity path exists. Then scope issuance policy by target service so one pipeline cannot carry broad access into every downstream system it touches.
Why this is a standing privilege problem, not just a secrets problem
A pipeline secret that can reach both Azure APIs and Salesforce is doing more than authenticating a job step. It is acting as a reusable privilege path across trust boundaries, which means the key question is not where the secret lives, but what it can do and for how long. The safer pattern is to replace that reusable path with a verifiable workload identity and then constrain issuance to the specific downstream service.
That shift matters because pipeline secrets tend to accumulate standing access. A token that can authenticate to one service often gets copied, reused, or widened until it becomes a generic integration credential. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it frames the exact failure mode: hardcoded or overly shared secrets become hard to inventory, rotate, and scope once they start crossing environments.
Once a workload identity path exists, the secret should be removed from the pipeline rather than kept as a fallback. A parallel secret path usually lingers long after the new auth path is live, and that creates dual control points, duplicate audit trails, and a much larger blast radius if either path is abused. The operational objective is to get to one bounded path per service interaction, not multiple equivalent ways to reach the same API.
How to scope access so one pipeline cannot become a universal key
Scope issuance policy by target service, not by the convenience of the pipeline. Azure and Salesforce should not inherit the same broad credential just because they are both downstream systems. The credential or assertion presented to Azure should only work for the Azure use case, and the Salesforce path should be separately bounded by audience, grant type, rotation, and expiry.
That is the practical value of Secrets Management Guide, which emphasizes secretless patterns, dynamic secrets, and moving away from long-lived shared material. It aligns with the answer here because the control goal is not merely to store the secret better, but to make the pipeline stop being a standing credential carrier.
For service-to-service access, the safest design is narrow, service-specific issuance plus short-lived credentials with explicit audience restrictions. If a single integration token can touch both cloud control-plane APIs and CRM data, it is already too broad. In practice, that usually means separate identities, separate trust policies, and separate rotation or revocation paths for each downstream system.
What good remediation looks like in practice
The first fix is to inventory every place the pipeline secret is accepted, then remove direct secret use wherever a workload identity or federated path can replace it. Next, confirm that each downstream service has its own trust boundary and that the pipeline can only request what it needs for that one service. For a path that reaches both Azure APIs and Salesforce, that typically means two distinct authorization decisions, not one shared token.
NHIMG’s Static vs Dynamic Secrets section is a good reference point because it captures the practical trade-off between long-lived credentials and ephemeral ones. The key judgement is that static secrets are acceptable only when there is no better path, and even then they should be tightly scoped, short-lived where possible, and on a clear retirement plan.
If the same pipeline needs both Azure and Salesforce access, do not solve that by expanding one credential. Split the trust relationship by service, verify the workload identity path for each target, and then retire the original pipeline secret once the last dependency has been cut over. That is what prevents a single compromised build job from turning into broad downstream data access.
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 surface, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Pipeline secrets that reach Azure and Salesforce are standing identity material. |
| NHI-07 — Long-Lived Secrets | The question is about removing a persistent secret path from CI/CD. | |
| NHI-05 — Overprivileged NHI | One secret reaching multiple downstream services indicates excessive access scope. | |
| Recommendation — Eliminate exposed pipeline secrets and replace them with short-lived workload identity paths. Prefer ephemeral credentials and revoke long-lived pipeline secrets as soon as federation exists. Scope each downstream trust relationship to the minimum target service and action set. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The answer hinges on replacing and retiring pipeline authenticators safely. |
| AC-6 — Least Privilege | Service-specific issuance and reduced blast radius are least-privilege decisions. | |
| IA-9 — Service Identification and Authentication | The recommended fix is workload-to-service authentication instead of shared secrets. | |
| Recommendation — Manage, rotate, and retire authenticators as soon as a better workload identity path is available. Limit each pipeline credential to only the specific downstream service and task it needs. Use service-to-service authentication paths instead of shared static pipeline credentials. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is control of downstream access granted through pipeline credentials. |
| A.8.24 — Use of cryptography | Replacing reusable secrets with stronger authenticated paths commonly depends on protected secret material and tokens. | |
| Recommendation — Apply access control so each integration can reach only its approved target service. Protect credential material with approved cryptographic and token-handling practices. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Dynamic Policy Enforcement | Service-specific issuance and bounded trust reflect dynamic, per-request authorization. |
| Recommendation — Enforce per-service access decisions instead of granting broad standing trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | The pipeline secret functions as an account-like access path that must be removed or constrained. |
| Recommendation — Remove unused access paths and scope remaining service credentials tightly. | ||
Practitioner Guidance
What to prioritise: Remove the pipeline secret first from the highest-impact target, usually the system with the broadest data or control-plane reach. If Azure APIs are used for deployment and Salesforce is used for data movement, treat them as separate blast-radius decisions rather than one shared access problem.
What to verify: Confirm that the workload identity path is actually enforced end to end, including audience restriction, expiry, and revocation. A secret that still works after the new path is live means the migration is incomplete, even if the pipeline appears to function normally.
Common mistake: Teams often keep the original secret “just in case” after they add federated auth. That leaves two valid paths, which makes compromise easier and incident response harder because attackers can choose whichever path is least monitored.
Practitioner takeaway: The right control objective is not “protect the pipeline secret better”, it is “stop the pipeline secret from being a reusable privilege path at all.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org