IAM pitfalls and how to avoid them: the hidden risks in cloud and Azure environments

Written By Shaping Cloud

‍In the first piece in this series, we made the case that identity has become the new security perimeter. If we accept that, then it’s worth being honest about the state of the perimeter most of us are actually defending.

Across the cloud and Azure environments we see, the same handful of identity pitfalls turn up again and again. They aren’t novel. They aren’t zero-days. They’re the slow accumulation of small, sensible-at-the-time decisions that nobody ever revisited. And they’re now the things that cyber insurers, regulators, and auditors are getting noticeably less patient with.

In this blog, we want to walk through the pitfalls we see most often, why they matter, and what good looks like instead.

Over-permissioning has quietly become the default

Microsoft, Sonrai and Veza have all looked at this from different angles, and they keep landing in the same place. The over-permissioning problem isn’t really about our humans. It’s about the machine identities (service principals, managed identities, scripts, apps) that now outnumber humans by 4-to-1 or even 10-to-1 in the average cloud estate, and that nobody is reviewing.

The numbers are sobering:

That gap, between what identities can do and what they actually need to do, is where most of the real risk sits. And it shows up in the same predictable ways:

  • Global Administrator roles handed out for a one-off troubleshooting session and never revoked.

  • Owner permissions on subscriptions because Contributor “didn’t quite work” one Tuesday in 2022.

  • Service principals with Directory.ReadWrite. All because someone needed to get a script working before lunch.

  • Standing privileged access for people who only need it occasionally.

  • Permissions that move with people through every role change but never get shed.

Privilege creep is rarely the result of one bad decision. It’s the result of a hundred reasonable ones, in a system where granting access is easy and removing it is awkward.

The fix isn’t glamorous, but it works:

  • Make least privilege the default, not the exception.

  • Build a standardised role-based access control (RBAC) model that maps to job functions, not individual asks.

  • Use Privileged Identity Management so high-impact roles are time-bound and require justification.

Run regular access reviews so entitlements are revisited, not just granted.  

Conditional Access only works if you maintain it

Conditional Access is one of the most powerful controls in the Microsoft stack. It’s also one of the easiest to quietly break.

Things we often see:

  • Numerous policies, several contradicting each other.

  • Half of them in report-only mode since 2021.

  • Legacy authentication still enabled “just in case”.

The pattern is almost always the same: policies were added reactively, one exception at a time, and nobody ever went back to tidy up. The result is a control that looks robust on a slide but has more holes than a colander.

If your Conditional Access estate has grown organically, it’s worth a proper audit. Consolidate policies, remove stale exclusions, make MFA genuinely consistent (not “consistent except for the CFO’s PA, three contractors, and that one app from 2018”), and decide deliberately what your legacy authentication posture is rather than letting it drift.

The joiner-mover-leaver gap is where most damage gets done

Joiner-mover-leaver is the unglamorous bit of IAM that nobody puts on a conference slide, and it’s where most of the real damage happens. The Verizon 2024 Data Breach Investigations Report still finds stolen credentials as the single most common initial action in breaches. Every account that should have been disabled and wasn’t, every contractor account that outlived the contract, every service account with a password in a spreadsheet: all of them are credentials waiting to be reused.

The classic failure modes:

  • Accounts disabled but not de-licensed (or de-licensed but still authenticating).

  • Mailboxes converted to shared and then forgotten.

  • Contractor accounts that outlive the contract by years.

  • Movers who pick up the permissions of every team they pass through without ever shedding the previous ones.

  • Service accounts with passwords in a spreadsheet, no owner, and permissions to half the estate.

  • Someone called Dave who left in 2019 and is somehow still showing up in audit logs.

The fix is process, not product. Automate the joiner-mover-leaver workflow, tie it to your HR system as the single source of truth, and treat service accounts as first-class citizens with named owners, defined lifecycles, and managed identities wherever possible. If you can’t say with confidence who owns every privileged account in your tenant, that’s the place to start.

Shadow IT has quietly become identity sprawl

Every organisation has more SaaS than it thinks it does. Someone signs up for a free trial, hooks it into Microsoft 365 with broad consent, and moves on. Multiply that across a few hundred employees over a few years and we end up with a sprawling estate of unmanaged identities, OAuth grants, and integrations that nobody is reviewing.

The risk isn’t only the apps themselves. It’s the standing access they hold into our tenants, often with permissions that go well beyond what the original use case needed. Stale credentials, abandoned integrations, and forgotten OAuth grants are exactly the kind of low-effort, high-reward path attackers look for.

The mitigations are straightforward:

  • App governance and regular consent reviews.

  • A clear enterprise application policy with admin consent for anything sensitive.

  • Quarterly cleanup: what’s connected to our tenant, who owns it, and does it still need to be there?

Copilot doesn’t break your security. It exposes it.

The piece that ties all the others together is the one we haven’t talked about yet. AI assistants like Microsoft 365 Copilot don’t bring their own permissions. They inherit ours. Every SharePoint site, every Teams channel, every document a user can technically access becomes something Copilot can find, summarise, and surface in plain English on their behalf.

That’s a profound shift. For years, latent oversharing has been a theoretical risk, mitigated by the fact that nobody actually went looking through every site they had access to. Copilot will. And it will do it in seconds, in response to a casual prompt.

Microsoft’s own Copilot deployment guidance now puts “remediate oversharing” as the first pillar of a secure rollout, ahead of guardrails and compliance. That isn’t a marketing position. It’s an acknowledgement that most tenants are not ready.

The patterns we see most often:

  • SharePoint sites shared with “Everyone except external users” because it was the path of least resistance years ago.

  • Broken permission inheritance on libraries that nobody has audited since the site was created.

  • “Anyone with the link” sharing left on by default.

  • OAuth grants and connectors with broad Microsoft Graph permissions that made sense for the original use case and have never been narrowed.

  • Legacy project sites, M&A sites, and HR sites with permissions that reflect the org chart of three years ago.

None of this is new. What’s new is that AI removes the friction. The question isn’t whether someone could find that 2022 redundancy spreadsheet by clicking through SharePoint. It’s whether Copilot will put it in a tidy summary the moment someone asks the right question.

This is why everything else in this blog suddenly matters more. Over-permissioning, joiner-mover-leaver gaps, shadow IT and stale OAuth grants stop being theoretical risks the moment AI tooling is switched on. If we want to use Copilot well, the prerequisite is the IAM hygiene we’ve been deferring for years.  

IAM is a discipline, not a project

This is the one that sits underneath all the others. IAM is often funded as a project (a migration, a rollout, a tidy-up before an audit) and then quietly declared done. The trouble is, identity isn’t a thing you finish. People join, leave, and change roles. Apps are bought, retired, and acquired.

Threats evolve. Regulations like NIS2 and standards like ISO 27001 increasingly expect ongoing assurance, not a one-off attestation.

If we don’t have continuous governance (regular access reviews, automated policy enforcement, central visibility across our tenants and clouds), we’re essentially relying on the estate not changing. Which it will, the moment our back is turned.

The organisations that handle identity well aren’t the ones with the biggest budgets. They’re the ones that have stopped treating IAM as a tidy-up job and started treating it as an ongoing discipline:

  • Least privilege as a default, not an aspiration.

  • Standardised roles tied to job functions.

  • Time-bound elevation for anything privileged.

  • Automated joiner-mover-leaver tied to a single source of truth.

  • Continuous governance with named ownership.

Final thought

None of these pitfalls are sophisticated. They’re the slow accumulation of small decisions, in environments that have grown faster than the controls around them. The good news is that the fixes are well understood, and the gap between organisations that get this right and those that don’t is almost entirely about discipline, not technology.

In the next piece, we’ll get into what that mature, ongoing IAM practice actually looks like in real life, and why the path to it is shorter than most people think.

Looking to move beyond IAM firefighting?

Addressing today's identity risks is only the first step. Shaping Cloud works with organisations to design and implement modern IAM solutions that reduce risk, simplify operations and support secure digital transformation across Azure and hybrid environments.

Explore our Cloud Identity & Access Management services.

Shaping Cloud
Next

Why identity has become the new security perimeter and why IAM now matters more than ever