When shared passwords are not revoked promptly, former employees may retain access to business applications long after departure. That creates an avoidable insider risk and makes it harder to prove who accessed sensitive data. It also weakens offboarding, because one credential can continue to work even after the person who knows it should no longer have any relationship to the organisation.
Why the Risk Persists After an Employee Leaves
Shared SaaS passwords are a control failure because departure does not automatically break access. If the password is still valid, the account remains usable by anyone who knows it, which means the organisation has no reliable way to tell whether a former employee, a teammate, or an unauthorised third party is using it. That is a lifecycle problem, not just a password problem.
The risk grows when the credential is used across multiple business applications, because one missed revocation can preserve access to several services at once. Shared passwords also weaken accountability: when multiple people know the same secret, audit trails may show only the shared account, not the actual person behind the action.
In practice, this is where offboarding and access governance intersect. NHIMG’s Ultimate Guide to NHIs and the NHI Lifecycle Management Guide both emphasise lifecycle control, while the 2025 State of NHIs and Secrets in Cybersecurity highlights how often organisations struggle to revoke and rotate access on time.
What the Failure Looks Like in Real Operations
The operational failure is usually simple: HR closes the employment record, but the shared SaaS credential is left untouched, forgotten, or embedded in a team workflow. The account may continue to work for weeks or months, especially if no one is tracking where the password is stored, who knows it, or whether the service has any secondary trust paths such as SSO, API tokens, or delegated access.
That creates three practical consequences. First, access persists beyond employment. Second, investigators cannot confidently tie SaaS activity to a single person. Third, the business may discover the gap only after an abnormal login, data access dispute, or vendor notification. A one-time shared secret can therefore become a standing access path long after the original reason for sharing has disappeared.
The same pattern is visible in broader secrets research. The Guide to the Secret Sprawl Challenge and The State of Secrets in AppSec both show how secrets become hard to track once they spread into files, tools, and team processes. For SaaS passwords, the problem is not only exposure, it is the absence of a clean ownership and revocation point.
Risk and Threat Considerations
When a shared SaaS password survives offboarding, the organisation keeps an access path open for anyone who knows the secret. That creates avoidable insider risk, weakens attribution, and can turn a routine departure into a latent compromise condition if the password is reused, forwarded, or stored insecurely elsewhere.
Failure mechanism: the credential is shared rather than individually bound, so revocation does not map cleanly to a person. If no one changes the password promptly, the former employee retains functional access and may also retain knowledge of the credential after the account should have been retired or rekeyed.
Impact: sensitive SaaS data can remain exposed, audit evidence becomes less trustworthy, and one stale password can preserve access to multiple applications or connected workflows. In a breach investigation, that also makes it harder to prove whether the access was legitimate, accidental, or malicious.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Shared Accounts and Shared Secrets | Shared SaaS passwords are a shared-secret and access governance problem. |
| NHI-03 — Lifecycle and Offboarding | Prompt revocation after departure is a core lifecycle control for shared credentials. | |
| NHI-06 — Secrets Discovery and Visibility | You cannot revoke what you cannot find across SaaS and workflow sprawl. | |
| Recommendation — Eliminate shared secrets and bind SaaS access to individual identities. Revoke and rotate credentials immediately when a user leaves. Inventory where shared passwords are stored and who can use them. | ||
| NIST CSF 2.0 | PR.AA-5 — Access Permissions and Authorization Management | Leaving shared passwords active preserves unauthorised access paths. |
| AU-2 — Audit Events | Shared credentials weaken attribution and make audit trails less reliable. | |
| Recommendation — Remove access promptly and confirm authorisation no longer exists. Log account use so access can be attributed and reviewed. | ||
| CIS Controls v8 | 5.3 — Disable Dormant Accounts | Former employees should not retain working access after offboarding. |
| 6.7 — Establish and Maintain Secure Configurations for Software | Shared SaaS passwords often persist because configuration and ownership are unclear. | |
| Recommendation — Disable or remove accounts and access paths during offboarding. Standardise SaaS access and remove shared credentials where possible. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | A still-valid shared password is a classic valid-account access path. |
| Recommendation — Hunt for and disrupt misuse of still-valid accounts after departure. | ||
Practitioner Guidance
What to prioritise: treat every shared SaaS password as a time-bounded exception with a named owner, a documented reason for sharing, and a mandatory revocation trigger on departure. If the service supports individual accounts, SSO, or role-based access, move away from the shared secret rather than trying to manage it indefinitely.
What to verify: confirm that offboarding includes password rotation, session invalidation, and review of any linked tokens or fallback logins. If the password is still needed for business continuity, verify who retains access, how access is logged, and how quickly the secret can be replaced without service disruption.
Practitioner takeaway: the key question is not whether the password was ever shared, but whether the organisation can revoke that access quickly, prove who used it, and eliminate it before it becomes a standing access path.
Related resources from NHI Mgmt Group
- What happens when employees keep using shadow SaaS after they leave the company?
- What happens when employees leave but their SaaS access is not fully removed?
- What happens when a SaaS account is breached after employees have already shared sensitive data with it?
- What breaks when shared SaaS accounts are left in place after employees change roles or leave?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
