Identity and Access Management: Why It's the Control That Actually Stops Breaches

Ask most security teams which control stopped their last close call, and the answer is rarely a firewall rule or a patched CVE. It's usually an identity control: a privileged account that required MFA an attacker didn't have, a stale account that had already been deactivated, or a permission that was scoped too narrowly to matter once it was compromised. Identity and Access Management (IAM) doesn't get the attention that penetration testing or compliance certificates do, but in our assessments it is consistently where the gap between "secure on paper" and "secure in practice" shows up.

Why IAM Keeps Causing Breaches

Three patterns account for most IAM-related incidents we see in UAE organisations:

• Permission creep. Employees accumulate access as they move roles or take on temporary projects, and nobody removes the old access afterwards. Years later, a marketing coordinator can still read the finance system they touched once for a campaign report.
• Shared and standing privileged accounts. A single "admin" login used by several engineers, with no individual accountability and no time limit on when that privilege is actually needed.
• Orphaned accounts. Former employees, contractors, or decommissioned service integrations whose credentials were never disabled — a fact an attacker doing basic reconnaissance will find before your own access review does.

None of these require a sophisticated exploit to become a breach. They just require someone — an insider, a phished employee, or an attacker who's already landed a foothold — to reach an account that has more access than it should, for longer than it should.

The Core Principles That Actually Matter

A working IAM programme doesn't need to be exotic. It needs these fundamentals applied consistently:

Least privilege, enforced not just stated. Access should map to what a role genuinely needs to do its job, reviewed against actual usage rather than what was convenient to grant at onboarding. Role-based access control (RBAC) is the right starting model for most organisations; attribute-based access control (ABAC) earns its added complexity only once you have genuinely dynamic access conditions (location, device posture, data sensitivity) to enforce.

Multi-factor authentication everywhere it matters. Not just on the email account — on VPN access, administrative consoles, cloud provider dashboards, and any system that can reach sensitive data or critical infrastructure. Password-only access to anything privileged is the single most common finding in our network penetration tests.

Time-bound, justified privileged access. Standing administrative access is a standing risk. Just-in-time (JIT) elevation — where an administrator requests and is granted elevated access for a defined window, tied to a ticket or approval — shrinks the window an attacker has to exploit a compromised privileged credential, and it gives you an audit trail that "always-on admin" never will.

Individual accountability. Every privileged action should be traceable to a person, not a shared account. This matters for incident response as much as for compliance — you cannot investigate what you cannot attribute.

Privileged Access Management (PAM): The Layer Most Organisations Skip

IAM governs who can authenticate and what they can generally reach. PAM is the more deliberate discipline sitting on top of it, specifically for the accounts that can do the most damage: domain admins, database superusers, cloud root accounts, and service accounts with broad permissions.

A functioning PAM approach typically includes:

• A credential vault so privileged passwords aren't memorised, shared, or hardcoded into scripts
• Session recording for privileged sessions, so an administrative action on a production system can be reviewed after the fact
• Just-in-time elevation rather than permanent privileged group membership
• Approval workflows for high-risk actions, especially in regulated environments

You don't need an enterprise PAM platform on day one. Even a disciplined manual process — a documented approval step, logged elevation, and a quarterly review of who holds standing privileged access — closes most of the gap a mature PAM tool eventually automates.

Access Reviews: The Habit That Keeps IAM Honest

A good IAM design decays without maintenance. Access review cycles — typically quarterly for privileged access and at least semi-annually for standard access — are what catch the creep before it becomes an incident. An effective review isn't a rubber stamp; it asks a manager or system owner to confirm, specifically, that each person on the list still needs that specific access, and removes anyone they can't justify.

Pairing access reviews with joiner-mover-leaver (JML) automation — so access changes the moment HR records a role change or termination — removes most of the manual lag that creates orphaned accounts in the first place.

IAM and Compliance: Where This Gets Mandatory, Not Optional

IAM maturity isn't just good practice — it's explicitly required by nearly every framework UAE businesses pursue:

• ISO 27001 (Annex A.9/A.5.15–A.5.18 in the 2022 revision) requires documented access control policy, user access provisioning, and periodic review of access rights
• PCI DSS 4.0 Requirements 7 and 8 mandate least-privilege access to cardholder data and strong authentication, including MFA for all access into the cardholder data environment
• SOC 2 auditors will specifically test your access review evidence and account deprovisioning timeliness under the security and (where relevant) confidentiality criteria
• CBUAE cyber risk expectations for banks and fintechs explicitly cover privileged access controls as part of IT risk governance

An application architecture review is often where IAM design flaws surface first — because access control decisions get baked into system design long before a compliance auditor or penetration tester ever looks at them. Catching an overly broad service account or a missing authorisation boundary at the design stage is dramatically cheaper than fixing it after the system is live, a theme covered in more depth in our guide to threat modeling.

A Practical Starting Roadmap

If your organisation hasn't formalised IAM beyond "everyone has an Active Directory account," a realistic first 90 days looks like:

1. Inventory every system, account type, and existing privileged account — you cannot secure access you don't know exists
2. Enforce MFA on every privileged and remote-access path immediately; this is the highest-impact, lowest-cost step available
3. Run a first access review, focused on privileged accounts, to find and remove the obvious orphaned and over-privileged entries
4. Document an access control policy mapping roles to access levels, so future provisioning has a standard to follow rather than ad hoc judgment calls
5. Schedule recurring reviews — quarterly for privileged access is the realistic minimum cadence that keeps the programme from decaying again

FAQ

What's the difference between IAM and PAM?

IAM is the broader discipline covering how all users authenticate and what they're authorised to access across an organisation. PAM is a focused subset dealing specifically with privileged accounts — the ones that can make system-wide changes, access sensitive data broadly, or disable security controls — and typically adds vaulting, session recording, and time-bound elevation that general IAM doesn't.

Do we need an IAM or PAM tool, or can we start without one?

You can and should start without one. A documented access policy, enforced MFA, and a manual quarterly review process will close most of the risk. A dedicated platform becomes worthwhile once the manual process can't keep pace with your headcount or the number of privileged accounts you're tracking — not before.

How does IAM relate to a penetration test?

A penetration test will often exploit a weak IAM control rather than a software vulnerability — a default credential, an over-permissioned API token, or a privilege escalation path between roles. Fixing the IAM foundation reduces what a pentest can find and exploit; it doesn't replace the need for testing, but it changes what the test uncovers from "critical" to "already mitigated."

How often should access reviews happen?

Quarterly for privileged and administrative access is the practical minimum most frameworks expect. Standard user access can run on a semi-annual cycle, provided your joiner-mover-leaver process already removes access promptly when someone changes roles or leaves. Reviews after any major reorganisation or system migration are worth adding regardless of the regular schedule.