Identity has become the perimeter that matters. A practical look at the IAM mistakes that still lead to breaches — and what good looks like in practice.
For years, security teams were taught to think in terms of edges, boundaries, and the network perimeter. That made sense when most users, systems, and data sat inside infrastructure the organisation owned and controlled. It makes far less sense now. Staff work remotely, applications live across cloud platforms, suppliers plug directly into shared systems, and automation now acts with privileges that used to belong only to people.
In that world, identity has become the control point that matters most. If an attacker can authenticate successfully, or abuse an account that already has access, many traditional security layers become much less relevant. That helps explain why so many serious incidents now begin with a stolen credential, a weak service account, an over-privileged administrator, or a trust relationship nobody has reviewed in far too long.
Most organisations know this in theory. The difficulty is that many identity and access management programmes still carry the habits of an earlier era. The tooling may be newer, but the underlying assumptions often are not. The result is a gap between what boards believe is under control and what operational reality actually looks like day to day.
Why Identity Now Sits At The Centre Of Security
The traditional model assumed there was an inside and an outside. Once a user or system was on the trusted side of the boundary, access became easier and scrutiny often reduced. Cloud adoption, SaaS usage, hybrid working, and third-party integration have steadily eroded that model.
Access decisions now happen everywhere. Employees sign in from managed laptops, personal mobiles, home broadband, hotel Wi-Fi, and customer sites. Contractors need limited access for fixed periods. Applications call other applications. CI/CD pipelines deploy to production using non-human credentials. Data moves between platforms the business does not fully own.
In that environment, identity is not just an administrative function. It is one of the main ways the organisation decides who gets access, how much access they get, and how quickly that access can be withdrawn when something goes wrong. If those controls are weak, attackers do not need to “break in” in the old sense. They can simply sign in, look legitimate, and get to work. That makes IAM a resilience issue as much as a security one. The faster an organisation can understand, constrain, and revoke access, the better its chances of containing harm before it spreads.
The IAM Mistakes That Keep Showing Up
By now, the fundamentals are well understood. Least privilege, good lifecycle management, strong authentication, meaningful monitoring, and sensible governance are hardly new ideas. Yet the same weaknesses still turn up in assessments and post-incident reviews. Usually the problem is not a complete absence of controls. It is partial implementation, uneven coverage, and too many exceptions left to age quietly in the background. In other words, identity often fails in governance long before it fails in technology.
1. Treating MFA As The Finish Line
Multi-factor authentication is essential, but it is not the end of the conversation. Many organisations roll it out widely, report success, and move on, while leaving awkward corners of the estate less protected than the headline suggests. Legacy protocols, recovery workflows, privileged accounts, supplier access, and help desk processes often remain softer than the main user journey.
Attackers are well aware of this. They do not need to challenge the strongest route into the estate if weaker routes are still available. MFA fatigue, token theft, adversary-in-the-middle phishing, and abuse of account recovery have all shown that MFA improves security materially, but does not make identity compromise disappear.
The real question is whether MFA is applied consistently to the accounts that matter most, and whether it is backed by sensible conditional access policies. A mature approach pays close attention to administrators, risky sign-in patterns, odd device posture, and implausible travel events rather than assuming one control will do all the heavy lifting.
The trade-offs go deeper than which factor type to use. Authenticators that sync codes through provider clouds — convenient as that is — create an additional channel through which a second factor can be silently exfiltrated. We built Signet the way we did for that reason: offline TOTP, no cloud sync, no account, no telemetry. It is not the right answer for every user, but for accounts that matter most it removes one of the categories of compromise that broader MFA programmes can leave open.
2. Letting Privilege Creep Become Routine
Privilege creep is one of the oldest identity problems around, and still one of the most damaging. People move roles, join projects, cover for colleagues, or inherit temporary responsibilities. Access is added quickly because the business needs to keep moving. It is removed much more slowly, if at all.
The result is predictable: users end up holding rights they no longer need, and sometimes rights they never should have had in combination. That might look untidy from a governance point of view, but it becomes a much bigger issue when one of those accounts is compromised. The attacker does not inherit what the user needs today. They inherit everything that has accumulated over time.
Least privilege is easy to support in principle and much harder to maintain in practice. It depends on access reviews that people take seriously, role design that reflects the way the business actually works, and owners who are prepared to challenge access that has simply become normal through habit.
3. Paying Too Little Attention To Non-Human Identities
Many IAM programmes still focus mainly on the workforce population. Meanwhile, service accounts, automation identities, API keys, secrets, and application-to-application trust often receive far less scrutiny. That is a problem, because these identities frequently have broad permissions, poor ownership, and credentials that live far longer than anybody would tolerate for a human user.
They are also attractive to attackers for obvious reasons. A stable service identity with generous permissions and weak monitoring can be far more useful than a standard user account. Security teams often hesitate to tighten these controls because they are worried about breaking production services. Over time, that caution can harden into neglect.
If organisations want to reduce this risk, they need a proper inventory of machine identities, named owners, controlled credential rotation, good secret management, and monitoring that treats non-human behaviour as something worth investigating, not background noise.
4. Leaving Old Accounts Behind
Stale access is rarely glamorous, but it remains one of the simplest ways to reduce risk. Dormant user accounts, old supplier identities, abandoned project accounts, and application credentials with no obvious owner all create exposure the organisation does not need.
This gets worse during periods of change. Mergers, restructures, contractor churn, acquisitions, and rapid growth all tend to create identity sprawl. If joiner-mover-leaver processes are inconsistent, access survives well beyond its useful life.
The real test of IAM maturity is whether revocation happens by design or by memory. Access should not depend on somebody remembering to file a ticket after an employee leaves or a supplier engagement ends. Where possible, deprovisioning should follow automatically from authoritative HR, procurement, and supplier management processes.
5. Underestimating Federated Trust And Third-Party Access
Federation and external identity integration make a great deal of operational sense. They reduce friction, improve user experience, and can simplify administration. They also expand the trust surface.
When an organisation accepts assertions from another identity provider, or allows a supplier tenant to access shared systems, it is placing trust in controls it does not operate directly. That does not make federation unsafe, but it does mean the relationship needs governance.
Security teams should know which external parties can authenticate into their environment, what level of assurance sits behind those identities, how privileged access is constrained, and what monitoring exists if something unusual happens. Too often, these trust relationships are set up for convenience and revisited only when an incident forces the issue.
What Better Looks Like In Practice
The organisations that handle identity well are usually not the ones with the most elaborate dashboards. They are the ones that keep the basics in good shape and stay disciplined about them.
In practical terms, that means:
- using phishing-resistant MFA for higher-risk accounts where possible
- reviewing privileged access more often than standard user access
- designing roles around real business need rather than historical sprawl
- applying proper governance to service accounts and other non-human identities
- tying identity lifecycle management into HR, procurement, and supplier offboarding
- monitoring authentication anomalies, privilege changes, token misuse, and unusual administrative activity
- reducing standing privilege where just-in-time or time-bound access is workable
None of that is especially fashionable. It is simply what good discipline looks like. Strong IAM is less about buying another platform and more about removing ambiguity over who has access, why they have it, and how quickly it can be changed. Organisations that do this well tend to be the same ones that treat cyber risk as an operational and governance concern, not merely an IT issue.
Identity Security Is As Much About Governance As Technology
One reason IAM problems linger is that they are often treated as purely technical. In reality, most of the difficult parts are organisational. Access models are vague because business roles are vague. Reviews are weak because ownership is unclear. Exceptions stay in place because nobody wants to challenge the operational convenience they provide.
That is why identity needs attention well beyond the directory team or the security function. It sits across cybersecurity, operations, third-party risk, compliance, and business governance. If identity is now the perimeter, then IAM cannot be treated as back-office plumbing.
For CISOs and security leaders, the message is fairly direct. A compromised identity is often the point at which a manageable problem becomes an enterprise incident. The organisations that fare best are usually the ones that remove unnecessary access early, review trust relationships properly, and assume that anything left unmanaged will eventually be tested.
At board level, this matters because identity underpins trust in the wider system. If you cannot say with confidence who has access to critical systems, data, and supplier-connected services, you cannot honestly say those assets are under control. That is why good IAM has become a defining part of modern cyber resilience rather than a background administrative task.