How to Revoke Developer Access to Production Secrets

A developer’s account can be disabled while their production access still lives on in an SSH key, token, or shared password. To revoke access safely, trace every path first, remove permissions, rotate exposed credentials, then check the logs to confirm the change worked.

Step 1: Identify the Developer’s Access Paths and Exposed Secrets

Start by mapping every route the developer could use to reach production secrets. Removing one cloud role won’t cut off a key stored on a server or access passed through a CI job.

Write down the person’s named accounts and machine identities. Check the cloud secret manager, identity provider, source control, deployment system, production hosts, databases, and any shared vault. Look for direct grants as well as access inherited through groups or roles.

In Google Cloud Secret Manager, open the secret, select it, and view its access details. Expand the role entry to see which users or service accounts have it. To revoke access, remove the relevant secret-access role from the policy.

Build a short inventory before changing anything. Note the secret or system, the identity that can reach it, the access type, and the owner who can confirm its use. Separate the developer’s own credentials from service accounts used by a team or application.

EnvManager centrally manages encrypted, version-controlled .env files with role-based access. If your team uses it, include each project and environment in the inventory, then check the member’s assigned access in EnvManager Roles & Permissions.

Also look for secrets copied into build settings, deployment variables, scripts, or local files. If a credential was visible to the person, assume it may need rotation even if you find no sign of misuse.

By now, you should have a list of access paths and credentials to review, not just a name to remove.

Step 2: Revoke Identity, Infrastructure, and Repository Access

To revoke developer access to production secrets, remove the identity’s grants at the source and in every connected system. Start with the access that can reveal or change production credentials.

In Secret Manager, select the affected secret and open its access details. Expand the role that grants access, remove the developer’s user or service account, then confirm the change. Repeat this for each production secret where the identity has direct access.

Next, check group membership and inherited cloud roles. Removing an individual grant won’t help if the person still belongs to a group with secret access. Apply the same check to production projects, deployment environments, databases, and server access.

Good access rules grant only the permissions a person needs for their work. Least privilege and separate duties can help limit the impact of a compromised or misused account.

Remove repository and CI/CD access as a separate task. Revoke active sessions or personal access tokens where the system supports it. Check build runners, deploy keys, and any service account the developer could manage. A shared account needs special care because removing one person won’t invalidate its credential.

For SSH access, find the person’s named public key on each production host and remove that key from the authorized keys list. Check certificates or access gateways too, if your team uses them. A key with a clear owner is easier to remove than a shared key with no record of who holds it.

Keep human accounts separate from workload identities. A CI service account may need to keep running after an employee leaves, but its permissions should belong to the pipeline, not the former developer. Review its owner and scope before you leave it in place.

Use EnvManager’s access-control checklist to compare environment-level permissions with the access a person still needs. Once access is removed, test the denial path using the affected identity or an approved test account.

Step 3: Rotate Secrets and Invalidate Active Credentials

Removing a user’s role doesn’t change a secret they already saw or copied. Rotate credentials the developer could read, especially shared passwords, API keys, signing keys, and long-lived tokens.

Start with credentials that protect production data or allow deployments. For each one, identify the applications and jobs that use it. Then create a replacement credential in the system that owns it, update its approved consumers, and check that they work before you disable the old value.

Use an overlap only when the provider supports it and your runbook allows it. During the overlap, watch for requests made with the old credential. Once the new value is confirmed in production, revoke the old one. If you suspect active misuse, don’t leave the old value live just to make a tidy cutover. Follow your incident process and prioritize stopping access.

Invalidate active sessions and tokens where possible. Deleting a role may block new reads but won’t always end an existing session at once. Check the identity provider and each service for ways to revoke sessions, tokens, or credentials already issued.

Handle SSH keys by removing the public key from every host that trusts it. If it was shared, replace it for all users who relied on it. For future access, issue separate keys to named users so a single departure doesn’t force a full team reset.

EnvManager can keep .env values centrally managed and version-controlled, with access assigned by role. That gives teams a defined place to update values used in local development and CI/CD instead of relying on copied files. For its API keys, rotate by creating a replacement, updating the pipeline, confirming a successful run, and then revoking the old key.

If a secret has appeared in a repository or build log, rotation comes before cleanup. Removing the text from a file or history doesn’t make the exposed credential safe again. After revocation, clean up copies and check whether the same value was reused elsewhere.

Before moving on, confirm that each replacement works and that the old credential no longer grants access.

Step 4: Check for Unauthorized Use and Verify the Revocation

Don’t treat a saved access change as proof that the person is locked out. Verify the current policy, then review activity around the offboarding or suspected exposure.

Return to each affected secret’s access details. Confirm the developer’s identity is no longer listed under a direct role. Then inspect inherited project and group permissions. A user can disappear from one secret’s policy and still reach it through a broader grant.

Search Cloud Audit Logs for activity tied to the user, service account, and affected secrets. Review reads, policy changes, and failed access attempts around the time access was removed. Review the platform’s access and monitoring controls.

Keep the review focused on what the logs can show. A read event may indicate access, but it won’t prove what happened to a value after it was retrieved. Check related systems too, such as build logs, deployment records, source control, and database audit logs.

Test that the old identity can no longer read the secret. Use an approved test account or a controlled session rather than asking someone to try with a personal account. Test the service’s normal access path as well, so the revocation hasn’t broken a workload that should keep running.

If you find suspicious use, treat it as an incident. Preserve the relevant logs, tell the incident owner, and rotate any credential that may have been accessed. Check for unusual deployments or changes made with the identity before the access was removed.

Record what you checked and what you found. That note gives the next reviewer a clear answer to two questions: was access removed, and did anything happen before it was?

Step 5: Document the Offboarding and Prevent Access From Returning

Close the loop by recording each change and assigning an owner for anything that remains. A clear record makes it easier to answer audit questions and repeat the same process during the next team change.

Document the identity, systems checked, access removed, credentials rotated, and time of each action. Note any service accounts you kept, why they remain, and who owns them now. Store the record in your approved ticket or change system, not in an informal chat thread.

Make the review part of offboarding, not a task someone remembers later. Tie the departure workflow to a checklist that covers cloud roles, secret stores, repositories, CI/CD, SSH access, and active tokens. Assign each system to a team that can confirm the change.

Use role-based access instead of one-off grants wherever possible. Keep production separate from development and staging. Give people only the access their current tasks require, and use temporary elevation for work that needs extra permissions for a short time.

Review access on a set schedule and after team changes. The right interval depends on your risk and workload; the important part is that someone owns the review and follows through on stale access. Keep a list of human users separate from service identities so a departing employee’s removal doesn’t leave machine access unclear.

EnvManager provides role-based access for centrally managed .env files, with controls to set each team member’s environment access. That can help reduce scattered copies, but it doesn’t replace reviews of cloud roles, repository keys, or credentials outside EnvManager.

Finally, test the offboarding checklist before an urgent departure. Run it against a non-production identity and check whether every system has a clear owner and a way to verify removal. Fix gaps while the work is calm.

FAQ

What should I revoke first when a developer leaves?

Remove access to production secret stores and privileged identity groups first, then work through connected systems. For how to revoke developer access to production secrets, don’t stop after disabling the main account. Check inherited roles, CI/CD, repositories, SSH keys, and active tokens so another path doesn’t remain open.

Does deleting a developer’s account revoke secrets they already copied?

No. Account removal can block future access, but a copied password, API key, or token may still work. Rotate any shared or sensitive credential the developer could have viewed, then confirm that applications use the replacement. If you suspect misuse, follow your incident process and revoke the exposed value promptly.

How do I verify that production secret access was revoked?

Check the secret’s current IAM policy and confirm the user or service account no longer has direct or inherited access. Then review audit logs for activity around the change. Test access with a controlled identity and check the normal workload path, too. This verifies both that the person is blocked and that intended services still run.

Should I rotate every production secret when one developer leaves?

Not always. Rotate secrets the person could read, shared credentials, and any value that may have been exposed. A separate secret that the developer could never access may not need rotation. Use your access inventory and log review to set the scope, then record why any credential was left unchanged.

How can teams make secret offboarding easier?

Use named accounts and keys, separate access by environment, and keep a central record of secret owners. Give production access only to people who need it. For how to revoke developer access to production secrets consistently, connect offboarding to a checklist and verify each system instead of relying on one account-disable action.

Conclusion

Revoke the identity’s access, rotate credentials it could have seen, and verify the result in policy and audit logs. Start by making an access inventory for one production service, then use it to test your offboarding checklist before the next departure.