IAM & PAM: The Domain That Controls Everything Else

Most breaches don’t start with a zero-day exploit.

In mid-2024, a threat actor tracked as UNC5537 accessed nearly 165 Snowflake customer environments. No vulnerability was exploited at entry. The attackers used credentials — harvested through info-stealer malware from developer machines and contractor laptops — against accounts that had no multi-factor authentication enabled. Ticketmaster lost data on roughly 500 million customers. Santander, AT&T, and dozens of others followed. The root cause across nearly every victim was the same: valid credentials, no additional verification, unrestricted access.

In early 2025, Marks & Spencer was hit by a ransomware attack linked to Scattered Spider. Initial access came through social engineering of IT helpdesk staff — attackers impersonated an employee convincingly enough to trigger a password reset and gain entry. From there, they moved laterally through privileged accounts, encrypted production systems, and caused what analysts estimated as hundreds of millions in losses. The business went dark for weeks.

Different attackers, different techniques, different industries. Same underlying failure: identity controls that weren’t good enough to stop someone who found their way in.

Identity is how attackers move. And Identity & Access Management — IAM — is the discipline built entirely around controlling that movement.

If you’ve worked in IT for a few years — sysadmin, helpdesk, cloud infrastructure — there’s a real chance you’ve been touching IAM work without realising it had a name.

The problem IAM exists to solve

Every organization has the same question running underneath everything it does: who should be able to access what, and under what conditions?

That sounds simple. It isn’t.

A mid-sized enterprise might have thousands of employees, hundreds of applications, dozens of cloud environments, external contractors, service accounts running automated processes, and APIs talking to APIs — all of it needing some form of access control. Get it wrong in one place and an attacker who compromises a single account can move laterally across the entire environment.

The reason identity became so critical over the last decade is a structural shift in how computing works. The old security model assumed a defended perimeter. If you were inside the network, you were probably legitimate. Firewalls and VPNs were the gatekeepers.

That model collapsed. Cloud, SaaS, remote work, and contractor ecosystems destroyed the boundary. When your finance team runs Workday from home on a personal laptop, the firewall sitting in your data centre stops being meaningful. The question stopped being “are you inside our network?” and became “who are you, what are you accessing, and does that make sense right now?”

This is what Zero Trust actually means at a practical level. Not a vendor product. Not a compliance checkbox. A design principle: never trust implicitly, always verify identity and context. IAM is the infrastructure that makes Zero Trust real.

What IAM, PAM, and IGA actually are

IAM is a domain with three distinct sub-areas worth understanding separately, because they have different tooling, different career paths, and different hiring profiles.

Identity Governance and Administration (IGA) is about the lifecycle and oversight of access. Who has access to what, does that access still make sense, and can you prove it to an auditor? Joiners get provisioned correctly. Movers get their old access removed and new access granted. Leavers get fully deprovisioned — not partially, not three weeks later. Access certification campaigns happen on a defined schedule, where managers review and reconfirm what their teams need. Segregation-of-duties controls prevent one person from both creating a vendor and approving their invoice. In regulated industries — banking, healthcare, insurance, government — IGA is mandatory and deeply audited. Platforms: SailPoint IdentityNow and IdentityIQ, Saviynt, One Identity Manager.

Privileged Access Management (PAM) governs the high-stakes accounts. Domain admins. Root. Database superusers. Cloud admin roles with the ability to delete infrastructure or exfiltrate data at scale. These are the accounts every attacker wants. PAM is specifically designed to protect them: credentials are vaulted so nobody holds them permanently, sessions are recorded, just-in-time access means elevated privileges exist only for the duration of an approved request, and anomalous privileged behaviour triggers alerts. CyberArk is the dominant enterprise platform. BeyondTrust and Delinea — formerly Thycotic and Centrify — are widely deployed at mid-market and in government.

Core IAM / Access Management covers the authentication and authorisation infrastructure itself — Single Sign-On, MFA, Conditional Access policies, and the federation protocols that connect identity providers to applications. Okta and Microsoft Entra ID (formerly Azure AD) dominate this space. Most enterprises have one of these as their primary identity provider, and everything else connects through it.

And then there’s the area most organisations are currently losing control of: non-human identities. Service accounts. API keys. OAuth tokens issued to third-party SaaS integrations. Workload identities in Kubernetes pods. Machine-to-machine authentication in cloud-native pipelines. In most enterprises, non-human identities outnumber human ones — and they’re significantly harder to govern. The Snowflake incident involved credentials harvested from developer environments and service accounts, not just employee logins. Non-human identity management is where the next decade of IAM work is concentrated.

What the work actually looks like

The experience varies considerably depending on your level and where you sit.

Entry level, in-house: You open a queue. Access requests in ServiceNow — someone needs a SharePoint site, someone else needs a database role. You provision them, verify the approvals are correct, document it. You run access certification campaigns through SailPoint, chasing managers to confirm their team members still need what they have. You handle MFA enrolment issues and Conditional Access troubleshooting — why can’t this user authenticate from home? Is it a policy gap, a device compliance failure, or a directory misconfiguration? It’s ticket-heavy. Not particularly exciting. But you’re learning the entire environment from the inside — which systems connect to which identity provider, where the exceptions live, why certain design decisions were made.

Mid level, in-house : You stop processing requests and start designing controls. You build Conditional Access policies — enforcing MFA for all external access, blocking legacy authentication protocols, requiring compliant devices for sensitive workloads. You design RBAC models, which means sitting with application teams to understand what roles actually exist, what permissions map to which job functions, and then getting it enforced rather than just documented. You configure CyberArk vaults, set up session recording for admin accounts, implement JIT access workflows. You automate lifecycle operations with PowerShell. You troubleshoot SAML federation failures and deal with the fallout when an authentication certificate expires overnight.

Consultancy: The work is episodic and broader. You’re brought into client engagements — a PAM implementation, an IGA programme, a Zero Trust assessment, an Entra ID deployment. You run discovery workshops, map the client’s identity landscape (which is almost always worse than anyone admits), produce architecture documents, implement the solution, and hand it over. The clients rotate. The problems vary. A significant part of the job is navigating the politics around access governance — convincing business owners to give up access their teams have held for years with no legitimate justification.

Vendor or product side: You’re either building the platform or helping customers deploy it. Professional services at a PAM or IAM vendor means you’re the deep subject matter expert on that toolset. High demand, high compensation, deep expertise in one platform.

How to get in — by background

From sysadmin or Active Directory admin: You’re closer than you think. If you’ve managed AD — provisioned users, maintained group memberships, configured GPOs, worked with OU structures and service accounts — you’ve been doing IAM operations without the title. The shift is adding a security lens to what you’ve been doing operationally. What are the attack paths through the directory you manage? Why does that service account have domain admin rights when it only needs to read one OU? Learn Entra ID to extend your on-prem knowledge into the cloud, pick up the attack concepts — Kerberoasting, Pass-the-Hash, DCSync — to understand what you’re now defending against, and target SC-300 as a near-term credential. Your AD background is a real advantage that cloud-native engineers don’t have.

From helpdesk or service desk: You see the identity lifecycle every day — password resets, account lockouts, MFA enrolment failures, new starter provisioning, leaver deprovisioning tickets. You have better intuition for how identity processes break down in practice than most engineers do. The move into IAM operations is natural. Start understanding the platforms behind the tickets you process. When Conditional Access blocks a user, understand why — not just what the ticket says, but what the policy is doing and why it was built that way. SC-300 or Okta Certified Professional gives you a credential to attach to the operational knowledge you already carry.

From cloud engineer or DevOps: You already manage IAM. You’ve written AWS IAM policies, configured Azure RBAC, granted GCP service account roles, and spent an hour debugging a 403 error that traced back to a missing resource-group permission. Your move is into cloud IAM security specifically — least-privilege enforcement, service account hygiene, CIEM tooling (Wiz, Orca, Ermetic), and secrets management with HashiCorp Vault or AWS Secrets Manager. Someone who understands both identity architecture and cloud infrastructure deeply is extremely difficult to hire. This is the scarcest combination in the current market.

From network engineering: Your entry point is the authentication infrastructure that connects to the network you’ve been managing — RADIUS, 802.1X, certificate-based auth for network devices, NAC. You understand how identity intersects with network access in ways that pure IAM practitioners often don’t. Zero Trust Network Access is replacing legacy VPN architectures, and that transition requires people who can bridge both domains. Identity-aware proxies, SD-WAN integration with identity providers, NAC policy enforcement — these are areas where your background gives you an angle that most IAM engineers lack.

What to learn — in phases

Phase 1: Protocols and foundations (months 1–2)

Before you touch a platform, understand what’s underneath it. Authentication vs authorisation — they’re distinct and frequently conflated. How LDAP actually works. What Kerberos does in an AD environment. The difference between SAML, OAuth 2.0, and OIDC — they solve different problems and aren’t interchangeable. When an SSO integration breaks, you’re debugging SAML assertions. When a service-to-service auth fails, you’re tracing an OAuth flow. This foundation is what separates someone who can troubleshoot from someone who can only follow runbooks. It has to come first because every tool you learn later sits on top of it.

Phase 2: Active Directory and one modern Identity Provider (months 2–4)

Most enterprises still run Microsoft AD as their identity backbone. Learn how users, groups, OUs, GPOs, and trust relationships work. Understand common AD attack vectors — Kerberoasting, Pass-the-Hash, DCSync — not to exploit them but to understand the environment you’re defending. TryHackMe and HackTheBox both have solid AD labs. Then go deep on one modern IdP: Entra ID if your background is Microsoft-heavy, Okta otherwise. Learn how SSO is configured from scratch, how Conditional Access policies work and where the exceptions create gaps, how MFA is enforced. Microsoft’s developer programme gives you a free tenant. Okta has a free developer org. Learn by building, not by reading.

Phase 3: PAM and Identity Governance (months 4–6)

This is where you move into higher-value territory. Understand how CyberArk works — credential vaulting, session isolation, JIT access workflows. You don’t need to be a CyberArk developer, but you need to understand the architecture well enough to design around it and explain it. BeyondTrust and Delinea are worth surface-level familiarity. On the IGA side, get familiar with SailPoint — how joiner-mover-leaver automation works, what an access certification campaign looks like, how segregation-of-duties rules are defined. Understanding IGA conceptually before you’ve deployed it makes a meaningful difference in conversations with hiring managers for governance-heavy roles.

Phase 4: Cloud IAM and automation (months 6–9)

AWS IAM, Azure RBAC, and GCP IAM each have distinct models and they’re all nuanced. Overly permissive cloud IAM policies are one of the most common findings on cloud security assessments. Learn how to audit them — what an overly-broad policy looks like versus one that actually follows least privilege. Pick up PowerShell at a working level for Microsoft environments. Python for cross-platform scripting and API integrations. Terraform for IAM-as-code in cloud environments. The ability to automate — access reports, lifecycle triggers, compliance checks — is what separates IAM engineers from IAM administrators at the mid level and above. Automation comes last in the learning path because you need context to know what’s worth automating.

Tools and technologies

Specific platform names that appear in job descriptions — know at least several of these before applying:

Identity providers and SSO: Microsoft Entra ID, Okta, Ping Identity, ForgeRock (now Ping), Auth0 (Okta), Google Workspace Identity

PAM platforms: CyberArk Privileged Access Manager, CyberArk Conjur (DevOps/secrets), BeyondTrust Password Safe, Delinea Secret Server, Delinea Privilege Manager

IGA platforms: SailPoint IdentityNow, SailPoint IdentityIQ, Saviynt, One Identity Manager

Cloud IAM: AWS IAM, AWS IAM Identity Center, Azure RBAC, Azure Privileged Identity Management, GCP IAM, GCP Workload Identity Federation

Secrets management: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager

ITDR (Identity Threat Detection and Response): Microsoft Entra ID Protection, CrowdStrike Falcon Identity Protection, Semperis, Silverfort — this is the hot emerging sub-area with very few experienced practitioners

CIEM (Cloud Infrastructure Entitlement Management): Wiz, Orca Security, Ermetic (Tenable Cloud Security)

Scripting and tooling: PowerShell, Python, Terraform, Active Directory Users and Computers, AD Explorer, SAML-tracer (browser extension for debugging federation)

Certifications — what actually moves hiring decisions

Microsoft SC-300 (Identity and Access Administrator): Start here if you’re targeting Microsoft environments. It’s technically substantive, covers Entra ID properly, and hiring managers at enterprise organisations specifically screen for it. Requires real platform knowledge to pass — not a paper cert.

Okta Certified Professional / Okta Certified Administrator: Valued in Okta-heavy environments, which represents a large portion of the market. The Administrator cert carries more weight than the Professional level. Both get you past HR screening for roles that list Okta as a requirement.

CyberArk Trustee and Defender: Vendor-specific, but CyberArk’s market dominance in enterprise PAM makes these certs genuinely portable. If you’re targeting PAM-focused roles, they’re frequently listed as preferred or required.

SailPoint IdentityNow Engineer / Architect: Relevant specifically for IGA-focused implementation roles. Increasingly listed as requirements for governance programme positions.

CompTIA Security+:Useful for establishing a general baseline if you have no security credentials at all. Required at some government contractors. Doesn’t move the needle independently in commercial enterprise IAM hiring, but it doesn’t hurt to have it.

AWS Security Specialty / AZ-500: Both certifications cover IAM substantively within their cloud context. Worth pursuing if cloud IAM is your primary direction.

CISSP: Relevant at the senior and architect level. Don’t pursue it early — you need the experience to sit it meaningfully and hiring managers can tell when someone passed it on theory alone. At the senior level, it signals broad domain competence in a way that platform-specific certs don’t.

The honest part: at mid-level and above, IAM hiring is heavily experience-driven. The cert gets you the phone screen. The ability to describe what you’ve actually designed, implemented, and debugged is what gets you the offer.

Where this path leads

Entry: IAM Analyst, Identity Administrator, Access Management Analyst Processing requests, running access reviews, learning the environment. This is also where helpdesk-to-IAM transitions naturally land.

Mid: IAM Engineer, Identity Security Engineer, PAM Engineer

Designing controls, owning platform areas, building automation. Platform expertise — Entra ID, Okta, CyberArk — largely determines your value at this level.

Senior: Senior IAM Engineer, Identity Architect, PAM Architect Senior IAM engineers.

Market demand is strong. Identity-related breaches dominating headlines, NIS2 and DORA driving compliance investment in Europe, and boards asking hard questions about credential hygiene — all of it is funding IAM programmes that have been underfunded for years. ITDR is emerging as a sub-specialisation with very few experienced practitioners, which means the entry window is open right now.

IAM also provides strong pivot paths. Mid-level IAM engineers move naturally into Security Architecture, Cloud Security, or GRC, where access governance and compliance requirements overlap heavily. The systems-level view of an organisation that you build in IAM is rare and valuable in adjacent domains.

Who this domain suits

IAM is structural, deliberate work. It rewards a particular kind of mindset.

You’ll thrive if you think in systems — you want to understand how a change propagates across an environment, not just what the immediate effect is. If you have patience for process — access certifications and governance reviews are important, unglamorous, and need to be done correctly. If you can navigate ambiguity and organisational politics — designing RBAC models means negotiating with business owners about what access their teams actually need versus what they currently hold. If you’re comfortable being the person who enforces least privilege when everyone wants admin.

You’ll find it frustrating if you need visible impact and constant novelty. IAM done well is invisible. Nobody thanks you for the ex-employee account that was deprovisioned on time. The successes are things that didn’t happen.

The practitioners who burn out in IAM tend to be those who wanted offensive security work and ended up here by accident. The ones who stay and grow are methodical, systems-minded engineers who find genuine satisfaction in building controls that work quietly and don’t fail.

One last thing worth knowing: IAM doesn’t get glamorised. You won’t see identity governance talks at DEF CON. But the security community quietly understands that identity is the actual control plane of modern enterprise security. When IAM is well-designed, attackers exhaust their easy options quickly. When it’s poorly designed, everything else — EDR, SIEM, firewalls becomes easier to route around.

That’s where the real leverage is.

CybersecurityRoadmap #IAM #PAM #IdentitySecurity #ZeroTrust #CybersecurityCareers