Post-breach analysis is one of the most consistent sources of security intelligence available. When incident reports, court filings, and regulatory disclosures describe how attackers moved through an environment, the same identity security failures appear with striking regularity.
These are not sophisticated zero-day exploits. They are basic identity hygiene failures that organisations know about, acknowledge as problems, and consistently fail to fix before they lead to incidents.
Here are the five that appear most frequently.
1. Orphaned Accounts with Active Permissions
The pattern: a contractor finishes an engagement, an employee changes roles, or a project ends. The accounts associated with that work are never deprovisioned. They sit dormant — sometimes for years — with the same access they had when they were active.
Attackers target these accounts specifically because they are less likely to have active monitoring. There is no legitimate user to notice unusual login activity. There is no manager to flag an access certification as inappropriate.
The fix is disciplined identity lifecycle management: automated deprovisioning when employment or engagement status changes, and regular access certifications that surface accounts with no recent activity.
2. Excessive Standing Privilege
The pattern: an administrator is granted elevated access to resolve an incident. The elevated access is never removed. Years later, that administrator account — or former administrator account — has permissions that far exceed anything required for their current responsibilities.
Privilege creep is universal. Every access governance programme acknowledges it. Most do not systematically address it because right-sizing access is operationally painful — it requires understanding what access is actually used, communicating changes that may generate user friction, and following up to ensure access is removed and not silently re-granted.
The fix is continuous right-sizing: automated analysis of actual access usage, regular certification of the gap between assigned and used permissions, and enforcement of time-limited access for elevated privileges.
3. Shared Credentials
The pattern: a team uses a shared service account to access a production system. The password is stored in a shared document, a password manager folder with broad access, or an environment variable that is visible to anyone with access to the deployment configuration.
When something goes wrong, attribution is impossible. Every member of the team with access to the shared credential is a suspect — and usually none of them are actually responsible.
Shared credentials also make rotation painful. Changing the password means coordinating the update across every system and team member that uses it — a coordination cost that means rotation happens rarely or never.
The fix is individual identity for every user and workload. No shared credentials. This requires a secrets management system that can issue individual credentials on demand — but the security and operational benefits are significant.
4. Credentials in Code
The pattern: a developer hardcodes a database password or API key in application code to make local development easier. The code gets committed to a repository — sometimes public, sometimes internal. The credential propagates through version history, CI/CD pipelines, and deployment artifacts.
This is the most common form of accidental credential exposure, and it is remarkably durable. Removing a credential from current code does not remove it from git history. Rotating the credential is only effective if every system that used the old value is updated, and if the old credential is actually invalidated in the upstream system.
The fix is pre-commit scanning, secrets detection in CI/CD pipelines, and — more fundamentally — a development workflow where credentials are never in code to begin with.
5. Unmonitored Privileged Sessions
The pattern: a privileged administrator accesses a production system. The access is logged but the session is not recorded. Weeks later, an anomaly is detected and the investigation team needs to understand what happened during administrative sessions in the window before the anomaly. The logs show that access occurred. They do not show what was done.
Without session recording, forensic investigations are limited to access events rather than access actions. The difference between knowing that a system was accessed and knowing what was done during that access is often the difference between a complete incident investigation and an inconclusive one.
The fix is privileged session recording for all production system access, with recordings stored in tamper-resistant systems accessible to the security team.
None of these failures require sophisticated attacker capability to exploit. They require only that the basic identity hygiene gaps exist — which they do, in most enterprise environments, right now.
The organisations that systematically address these five failure modes will have materially reduced their breach risk. The ones that treat them as known problems to be addressed eventually will eventually learn why “eventually” was not soon enough.