In May 2021 a ransomware attack led Colonial Pipeline to shut down the largest fuel pipeline on the U.S. East Coast, and the attackers didn't need a software flaw to get in. They signed in through a VPN account that was no longer in use but had never been disabled, protected only by a password that had turned up in a collection of leaked credentials. Colonial halted fuel deliveries for several days and paid a ransom of about $4.4 million.
On the CompTIA Security+ SY0-801 exam, stale credentials, rogue devices and shadow IT sit under objective 2.4, which expects you to recognize the kinds of vulnerabilities organizations carry and the places attackers find them. All three share a cause: something that can sign in, connect or hold company data exists outside the processes meant to control it. This lesson covers how each one arises, how to find it and how exam scenarios describe it.
Stale credentials keep working after the reason for them is gone
A stale credential is a valid account, password, key or token that nobody needs anymore or nobody is managing. It is dangerous precisely because it works. An attacker who finds one doesn't trigger failed-logon alerts or exploit anything; they sign in, and the logs record a normal logon by a legitimate account.
The common forms:
- Orphaned accounts: the owner left the organization, but the account was never disabled. Contractor and vendor accounts are the worst offenders, because they often sit outside the HR system that drives offboarding.
- Dormant accounts: the owner still works there but hasn't used the account in months, such as a VPN account left over from before a move to a new remote access product.
- Leftover access after a role change: the person moved departments and kept the old permissions alongside the new ones.
- Test, temporary and shared accounts created for a project and never removed, often with simple passwords.
- Default and built-in accounts that were never disabled or renamed.
Each has the same weakness: nobody would notice if it were used. The owner of a dormant account won't see an alert about a strange sign-in, and nobody reviews activity on an account everyone has forgotten. Old passwords make it worse. An account whose password hasn't changed in four years is likely to use one that has since appeared in a breach and is already on attackers' credential lists.
Service accounts and API keys go stale without anyone leaving
Not every credential belongs to a person. Service accounts run applications and scheduled tasks, API keys and tokens connect systems to cloud services, and SSH keys let scripts log in to servers. In most organizations these non-human identities outnumber employees, and they are managed far less carefully.
Their typical weaknesses:
- Service account passwords set once and flagged never to expire, because changing them might break the application.
- Far more privilege than the task needs, such as Domain Admin rights for a backup job.
- Cloud access keys that never expire on their own. An AWS IAM access key stays valid until someone deactivates or deletes it.
- API tokens and OAuth grants issued to third-party integrations, which keep working long after the project that needed them ends.
- SSH public keys left in authorized_keys files after an administrator leaves.
Third-party tokens deserve particular attention. In August 2025 attackers used OAuth tokens stolen from a sales chat integration to pull data out of the Salesforce instances of hundreds of companies that had connected the app. The victims' own passwords and MFA never came into play, because the integration's tokens were already trusted.
Credentials written into scripts and configuration files are a related problem. Hardcoded secrets in code are covered with application weaknesses.