Secret Rotation on Staff Change

When team members leave, rotate accessed secrets.

Trigger

When a team member leaves or changes roles, their access gets revoked. The discipline most teams skip: the secrets they had access to also need to be rotated. A shared API key the departed engineer used is still valid even after they are deprovisioned from the IDP; if they retained a copy, they retain access. Secret rotation on staff change is the close-out discipline that prevents this.

What triggers the rotation:

• Departure from the company.: Any employee leaving the company triggers the rotation. The departing employee's access is the obvious risk; their potential retention of secrets is the less obvious one. Both get addressed.
• Role change with reduced access.: An engineer who moves from the platform team to the product team no longer needs platform-level secrets. The deprovisioning happens; the rotation should follow. If the engineer had access to a shared production database password, that password gets rotated as part of the role change.
• Departure from a specific team.: Even within the same company, leaving a team that handles sensitive secrets warrants rotation of those secrets. The departed team member no longer has a need for the secrets; their potential retention is treated as risk.
• Identify shared secrets they accessed.: The first step is producing the list. Pull the secret-store audit log; identify which secrets the departed person fetched. The list is the input to the rotation; without it, the rotation is incomplete.
• Distinguish from individual credentials.: Individual credentials (the person's own SSH key, their own API token) are deprovisioned as part of normal offboarding. Shared credentials (database passwords, service API keys, OAuth client secrets) are what the rotation focuses on; their nature as shared means deprovisioning the person does not invalidate the credential itself.

The trigger is the departure or role change; the action is the rotation of shared secrets the person had access to. Both are required.

Rotate

The rotation itself is mechanical. The shared secrets identified in the trigger phase get new values; consumers of the secrets get updated; the old values are invalidated. The discipline is doing this thoroughly rather than cherry-picking the obvious cases.

• All shared secrets the person had access to.: Not just the high-impact ones. All of them. A small secret retained by a departed team member is still a credential they could use. The rotation covers the full inventory.
• Don't trust intent.: The default assumption is that the departed person retained copies of the secrets, even if they did not. The retention might be accidental (a credential cached in their password manager); it might be intentional. Either way, the rotation removes the risk regardless of intent.
• Cascade through dependents.: Each rotated secret has consumers (services, integrations, scripts) that need the new value. The rotation includes updating each consumer. The cascade is bounded if the inventory was good; unbounded if the inventory was incomplete.
• Time-bounded execution.: The rotation completes within a defined window after the trigger. Two weeks is a reasonable target. Longer windows leave longer exposure; shorter windows are operationally ambitious. The window is documented in the offboarding policy.
• Document the rotation.: Each rotation produces a record: which secrets, when, who triggered, who executed. The record feeds into the audit trail; future investigations can verify the rotation actually happened.

The rotation discipline is operationally heavier than just deprovisioning the person. The cost is real; the protection against post-departure misuse is the payoff.

Verify

The third leg is verification: confirming the rotation actually achieved its goal of preventing residual access. The verification catches the cases where rotation was incomplete or where the departed person had access through paths the team did not consider.

• No residual access.: The verification's goal is to confirm the departed person cannot use any of their old credentials to access company resources. The verification is concrete: try the old credentials; verify they fail.
• Test by attempting old credentials.: A controlled security test: try the departed person's old credentials against the systems they had access to. Authentication should fail; authorization should fail. If anything works, it is a finding to investigate and remediate.
• Audit logs cross-checked.: Review the audit logs for the period after the departure. Any access by the departed person's credentials in that window is suspicious; investigation determines whether the deprovisioning was incomplete or whether the credentials were used by someone else (a colleague who knew them, or an attacker who acquired them).
• Notification if anything works.: If the verification finds that some old credential still works, the security team is notified immediately. The credential gets revoked or rotated; the gap that allowed it is investigated; the offboarding process is updated to prevent recurrence.
• Document the verification.: The verification's results are captured in the offboarding record. The record is part of the compliance audit trail; it shows the team did the verification and what the outcome was.

Secret rotation on staff change is one of those quiet operational disciplines that distinguishes mature security programs. Nova AI Ops integrates with secret stores and HR systems, identifies the secrets a departing user accessed, automates the rotation cascade, and produces the verification reports the audit trail requires.