Jenkins credential scope decides what can use a secret. Global scope applies to Pipeline projects and their descendants. System scope applies to controller functions such as email authentication or agent connections. Credentials stored in a folder are available only to Pipelines in that folder. Use the narrowest option that works.
The levels
| Where defined | Who can use it |
|---|---|
| System scope | A single object, such as a controller function like email authentication or an agent connection |
| Global scope | Pipeline projects and their descendants, anywhere on the controller |
| Folder | Only Pipelines run from that folder |
The Jenkins credentials page puts the principle plainly: define each credential at the lowest level possible. Credentials defined at the controller level are available to all Pipelines that controller runs.
Why this matters
A global credential is reachable from any job. If one team can edit a Pipeline anywhere on the controller, it can try to use any global secret. Folder credentials shrink that circle to the people and jobs that need the secret.
Credential types
Jenkins supports secret text, username and password, secret file, SSH username with private key, certificate, and Docker host certificate authentication. Credentials can also be scoped to a specific user, not only to a project or the whole controller.
IDs
Pick a meaningful ID, such as one naming the system and purpose. After saving, an ID cannot be changed. If you leave it blank, Jenkins assigns a GUID. A clear ID makes audits and rotation easier, because you can see what a Pipeline is asking for.
Steps to tighten credentials
- List all credentials under Manage Jenkins, then Credentials.
- For each global credential, note which jobs actually use it.
- If only one team uses it, recreate it in that team's folder and update the Pipeline reference.
- Delete the old global copy once builds pass.
- Reduce who holds the Credentials Create permission. The docs advise starting with no access and granting it only to the people and projects that need it.
- Rotate the underlying secret, not just its place in Jenkins. Change usernames, passwords and tokens regularly.
Storage
Secrets are stored encrypted on the controller. The keys sit in the secrets directory under Jenkins home, with restrictive permissions, and do not belong in source control or routine backups.
Try it yourself
The demo shows an exploitability check, a way of asking which exposed secret or component actually matters.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans dependencies and enforces policies and gates in pipelines. See your own repository with the free scan.
Quick check
Can I rename a credential ID later?
No. Once set, an ID cannot be changed. Create a new credential and update references.
Where should a team specific secret live?
In that team's folder, so only Pipelines run from the folder can use it.
Sources
Last reviewed: 19 October 2026.
