Review it whenever vendors, contractors or automation no longer need standing access, and again after any change in project scope, ownership or integration design. Development ecosystems accumulate dormant permissions quickly, and those permissions become part of the exposure path if a partner account or connected tool is compromised. Least privilege only works when access is continuously revalidated.
When should third-party repository and pipeline access be reviewed?
Review third-party access whenever the access is no longer needed, and every time the operating context changes. That includes vendor offboarding, a contractor finishing work, a tool being replaced, a new integration being added, a repo or pipeline changing owners, or a project moving scope. The practical test is simple: if the third party no longer needs the same standing permission, the review is due.
Repository and pipeline access tends to expand quietly because it is granted to keep delivery moving. Over time, those permissions outlive the business reason that justified them. In development and CI/CD environments, that matters because a stale token, service account, or partner account can still reach code, secrets, artifacts, and deployment actions long after the relationship has shifted.
That is why review should be tied to lifecycle events, not just annual calendar checks. A change in integration design can be as important as a change in personnel, because the trust path may have moved from direct access to an API, or from a human contractor to an automation account. When the trust boundary changes, the access model should be revalidated at the same time.
Where does the risk come from if access is left in place?
The risk is not only that access exists, but that it remains valid after the original need has ended. In repository and pipeline environments, old access can expose source code, release credentials, build logs, secrets, and deployment controls. A compromised vendor account or connected tool can then become a path into your software supply chain, especially where permissions were granted broadly and never recertified.
This is particularly important because repositories and pipelines often hold higher-value material than teams realise. An account that can read a repo may also see configuration, credentials references, or release logic. A pipeline identity may be able to trigger builds, change artifacts, or move code into production. That means access reviews are not just a hygiene task, they are a control on blast radius.
Teams should also treat third-party access as a dependency risk. If the partner relationship changes, but the access does not, your environment still carries the partner’s past trust assumptions. The longer that mismatch persists, the more likely dormant permissions become part of the exposure path during a compromise or misconfiguration.
What should a useful review actually verify?
A good review confirms three things: the third party still needs access, the access is still bounded to the minimum required scope, and the account or token is still the right one to use. If any of those fail, the default outcome should be removal, reduction, or reissue with tighter limits. Standing access should be exceptional, not the starting point.
Reviewers should check both direct human access and delegated access used by tools. In practice, that means validating who owns the external identity, what repo or pipeline objects it can reach, whether the access is time-limited, and whether it is still tied to an active contract, project, or integration. Where possible, evidence should show the business reason for the access and the approval path that granted it.
For deeper governance, pair the review with entitlement cleanup and offboarding. That is the moment to remove orphaned tokens, rotate shared secrets, retire unused integration accounts, and tighten any permissions that were broadened temporarily during delivery work. A review that only records “still approved” but leaves the privilege unchanged is not a meaningful control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Covers periodic review and removal of unnecessary third-party accounts and entitlements. |
| IA-5 — Authenticator Management | Applies because repository and pipeline access often relies on tokens, keys, and other authenticators. | |
| AC-6 — Least Privilege | Directly supports limiting third-party repository and pipeline permissions to the minimum needed. | |
| Recommendation — Review and remove third-party accounts when they no longer have an approved business need. Rotate and retire stale tokens or keys tied to third-party access. Constrain third-party access to the minimum set of repos, pipelines, and actions required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Relevant because third-party repository access depends on active account lifecycle control and removal of stale access. |
| Recommendation — Inventory third-party accounts and disable those no longer tied to an active business need. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Supports review and adjustment of access rights as projects, vendors, and integrations change. |
| Recommendation — Review and revoke third-party access rights when the business justification changes. | ||
Practitioner Guidance
What to prioritise: Start with third-party identities that can reach production repositories, release pipelines, signing steps, or secret stores. Those are the access paths where stale permissions create the most expensive failure modes.
What to verify: Confirm that each external account, token, or automation identity still maps to a current business need, an active owner, and a narrow scope. If you cannot name the current owner or purpose, treat that as a failed review rather than a pending one.
Common mistake: Relying on periodic attestation alone while ignoring integration changes, project exits, and tool replacement. In repo and pipeline environments, lifecycle events are usually the faster signal that access has gone stale.
Practitioner takeaway: The best review cadence is event-driven with a periodic backstop, because access becomes risky the moment the trust relationship changes, not when the next audit arrives.
Related resources from NHI Mgmt Group
- What breaks when organisations do not control third party access in software delivery pipelines?
- Should organisations prioritise segmentation or access review first for third-party risk?
- When should organizations review access controls?
- How should organisations stop auto-sync from turning desktops into repositories of credentials?