Implementing Identity and Access Management in GCC

Why identity, not the perimeter, decides most breaches

A firewall stops a connection. It does nothing once an attacker is holding a valid username and password. Most enterprise breaches in the region now start with credential theft, a phished helpdesk reset, a reused password, an over-permissioned service account, rather than an exploited network device. Once an attacker has a working identity, the rest of the kill chain looks like normal user activity to most detection tools. That is why identity has become the control that decides whether an intrusion stays contained or turns into a full compromise.

The gap in most GCC organisations is not that IAM is unknown. It is that IAM gets deployed as a login screen and stops there. Single sign-on and multi-factor authentication solve authentication. They do nothing about authorisation drift: the slow accumulation of access rights that nobody removes because removing access is unpopular and reviewing it is tedious.

What IAM actually has to cover

IAM answers two questions for every account: who is this, and what should they be allowed to do. In practice that splits into four disciplines that are usually owned by different teams, which is itself part of the problem:

• Authentication: proving identity, through passwords, MFA, or increasingly passwordless methods tied to a device certificate.
• Authorisation: mapping identity to permissions, ideally through role-based or attribute-based access control rather than accounts collecting ad hoc grants over time.
• Lifecycle management: the joiner-mover-leaver process. An account should be created on day one with the access the role needs, adjusted when the person changes roles, and disabled the day employment ends, not weeks later.
• Governance: periodic access certification, segregation-of-duties checks, and an audit trail that shows who approved what and when.

The GCC-specific pressure

Regional regulation adds weight to identity controls without inventing anything new. NESA's information security standard, CBUAE requirements for licensed banks, and equivalent DESC and ADGM/DIFC expectations for regulated entities all converge on the same asks: identity governance, segregation of duties, and evidence of access review. None of them mandate a specific product. What an assessor actually wants to see is a joiner-mover-leaver log, a recent access certification with sign-off, and proof that privileged accounts are reviewed more often than standard ones.

That distinction matters because it explains why organisations pass an audit and still get breached through identity. A point-in-time compliance check does not catch an account that was reviewed six months ago and has since accumulated new access nobody signed off on. Compliance is a floor, not a detection control.

Where GCC IAM programmes actually stall

Budget is rarely the constraint. The recurring failure points are structural:

Fragmented ownership. IAM sits across identity teams, infrastructure, application owners, and HR. When no single role, reporting to the CISO or CIO, owns the end-to-end process, provisioning gets fast-tracked under deadline pressure and deprovisioning gets deprioritised because it has no deadline.

Legacy and hybrid identity. On-premises Active Directory federated to a cloud tenant through a sync connector is still the norm across regional banks and government entities. Every sync rule, every unmigrated legacy application with its own local account store, is a place where deprovisioning in the cloud does not propagate back on-premises, and vice versa.

Non-human identity growth. Service accounts, API keys, and application registrations now outnumber human accounts in most cloud tenants, and they are reviewed the least. A service account with standing write access to a database, created for a one-time migration and never revoked, is a common finding in cloud identity reviews.

Treating IAM as a project, not an operating discipline. A rollout with a start and end date produces a working system on day one and a decaying one a year later, because access keeps changing and nobody owns the ongoing review.

Privileged access comes first, not last

The highest-value fix in most environments is not a full workforce IAM rollout. It is getting control of privileged accounts: domain admins, database service accounts, cloud tenant owners, network device credentials. These accounts are fewer in number, carry disproportionate blast radius, and are the accounts attackers specifically hunt for once they land. A privileged access management layer that vaults credentials, rotates them, and records sessions closes this gap faster than a broader identity governance rollout, and it is where most mature programmes start before expanding to standard workforce access and then to partner and vendor accounts. The FAQ on IAM fundamentals covers the baseline terminology if the distinction between IAM and PAM is still unclear internally.

Cloud identity changes the failure mode, not the stakes

Moving identity to the cloud does not make it simpler. It changes what breaks. In Entra ID tenants, the common findings are over-permissioned application registrations with organisation-wide consent, conditional access policies that exempt legacy authentication protocols, and guest accounts from external tenants that never expire. In AWS, the equivalent is IAM roles with wildcard permissions attached because a deployment failed once under a restrictive policy and nobody tightened it back up afterward.

None of this shows up in a login screen. It shows up in a permissions audit, which is exactly the review most organisations skip because the cloud identity layer feels like someone else's problem once the migration project has closed out.

Detection has to sit next to governance

Access reviews catch what should not have been granted. They do not catch what is being actively misused right now. That is the job of behavioural monitoring: flagging a login from an unusual location, a finance account suddenly touching engineering systems, or a privileged session at an odd hour. Feeding identity and access logs into a SIEM, and layering user and entity behaviour analytics on top, turns IAM from a static control into something that can catch account misuse in progress rather than in a quarterly review. The UEBA guide goes into how that detection layer is actually built and tuned.

A realistic build order

Trying to fix identity everywhere at once is how programmes stall. A sequence that holds up in practice:

1. Get visibility first. Inventory every system with its own account store, including SaaS applications provisioned outside IT.
2. Lock down privileged and service accounts before anything else. This is the smallest set of accounts with the largest blast radius.
3. Automate joiner-mover-leaver by syncing account status to the HR system of record, so an account is disabled the day employment status changes, not when someone remembers to file the ticket.
4. Extend role-based access to standard workforce accounts, with periodic recertification built into the calendar, not treated as an annual scramble.
5. Federate partner and vendor access last, once internal hygiene is solid enough that external accounts are the exception being monitored, not one risk among many indistinguishable ones.

The decision that actually matters

If a programme cannot answer, right now, how long a departing employee's account stays active and who is accountable for privileged account reviews, the tooling underneath is close to irrelevant. Pick the one account type that would cause the most damage if misused in your environment, usually a domain admin, a cloud tenant owner, or a shared service account, and fix its lifecycle and monitoring first. Everything else in an IAM programme is sequencing after that.