How to Get an Identity and Access Management (IAM) Engineer Job in 2026-27

What an IAM engineer actually does, and the five different jobs sold under one title

Identity and access management is the plumbing that answers one question continuously: should this request, from this human or this machine, right now, be allowed. Everything else in the job is an implementation of that question. The reason the title confuses people is that five fairly different engineering disciplines all use it, and a posting will often name only the products, leaving you to work out which job it is.

Access management is the authentication and authorization surface. Single sign-on, multi-factor authentication, federation with external parties, conditional access or policy rules, session lifetimes, the login experience itself. The daily work is onboarding applications to single sign-on, writing and testing policy, and debugging why a particular federation stopped working. The products are Microsoft Entra ID, Okta Workforce Identity, Ping Identity, and the ForgeRock-derived platform now sold as PingOne Advanced Identity Cloud. If a posting lists conditional access, SAML, OIDC, passkeys and application onboarding, this is the job.

Identity governance and administration is the lifecycle and the evidence. Who should have what, how they got it, who approved it, when it was last reviewed, and what was removed when they left. The daily work is connectors to source and target systems, provisioning rules, role and entitlement modelling, access request workflows, certification campaigns, segregation of duties rules, and producing reports that survive an audit. The products are SailPoint (IdentityIQ on premises and Identity Security Cloud), Saviynt, Omada, One Identity, Oracle Identity Governance in older estates, and Microsoft Entra ID Governance in Microsoft-only shops. If a posting says joiner-mover-leaver, certification, recertification, SOX, entitlement, role mining or user access review, this is the job, and it is the one most people who land on this page are actually hiring for or applying to.

Privileged access management is the containment of the accounts that can do real damage. Vaulting credentials, brokering sessions so an administrator never holds the password, recording what was done, rotating secrets, and the long political project of removing standing administrative rights in favour of time-bound elevation. The products are CyberArk, Delinea, BeyondTrust, HashiCorp Vault, Teleport, and Entra Privileged Identity Management for Microsoft roles. If a posting lists vault, session recording, just-in-time elevation, tiered admin or break-glass, this is the job.

Customer identity, usually written CIAM, is a product engineering job wearing security clothes. Registration and login for external users at scale, social and passkey sign-in, consent, progressive profiling, fraud signals, and the conversion rate of the login page. The products are Auth0, Okta Customer Identity Cloud, Microsoft Entra External ID, PingOne, Amazon Cognito and increasingly self-hosted Keycloak. It pays well, it sits closer to engineering teams than to security teams, and it is a genuinely different job from governance. Do not apply to it with a governance resume.

The fifth area does not have a settled name yet and is the fastest growing: non-human identity. Service accounts, API keys, machine credentials, workload federation, and now autonomous agents. It is covered in the AI section below, because that is where the pressure is coming from.

The practical point for a job seeker: read the tool list in the posting before the responsibilities, decide which of the five it is, and tailor to that. Applying to a SailPoint governance role with a resume built around conditional access policy is how strong candidates get silently filtered. If you genuinely span two, say which one is deep and which one you can operate, in that order.

• Access management reads as: SAML, OIDC, conditional access, MFA, app onboarding, Okta or Entra.
• Governance reads as: joiner-mover-leaver, SailPoint or Saviynt, certification campaigns, SOX, entitlements, connectors.
• Privileged access reads as: CyberArk or Delinea or BeyondTrust, vault, session recording, just-in-time elevation, break-glass.
• Customer identity reads as: Auth0, Cognito, Keycloak, registration flows, consent, sign-up conversion.
• Non-human identity reads as: service accounts, secrets management, workload federation, machine identity, agent identity.
• Where the team sits tells you the job too: under the CISO means governance and risk pressure, under IT infrastructure means uptime and ticket pressure, inside a platform team means code and pipelines.

Joiner, mover, leaver: the experience employers are actually buying

If one phrase decides whether an IAM resume gets a call, it is joiner-mover-leaver, often shortened to JML or described as identity lifecycle management. It sounds administrative. It is the hardest part of the discipline, because it is where identity data meets an organisation that does not keep tidy records, and because its failure modes are exactly what auditors and attackers both look for.

The joiner is the easy third and the one most candidates can already describe. An authoritative source, normally the HR system (Workday, SAP SuccessFactors, UKG, ADP, Oracle HCM), publishes a worker record. The identity platform correlates it to an existing identity or creates a new one, generates a unique identifier that will outlive every name and email change, derives a username under a collision-safe rule, and assigns birthright access from attributes: everyone gets email and the intranet, everyone in Finance gets the finance file share, everyone in the Dublin office gets the Dublin badge group. Downstream systems get provisioned over SCIM where the application supports it, over a vendor API where it does not, and over a nightly file drop where you have no better option. The parts interviewers probe are the ones people skip: what happens on a pre-start record so the laptop and account are ready on day one without being usable before it, how you handle a contractor who has no HR record at all, and how you avoid creating a second identity for a rehire who already exists.

The mover is where the real engineering lives, and where most candidates fall apart. When somebody changes department, manager, location, job code or employment type, adding the new access is trivial and removing the old access is not. Entitlements accumulate because removal breaks things and nobody wants to be the person who broke something. A credible answer describes recalculation rather than addition: the platform recomputes what the identity should have from current attributes, compares it to what the identity does have, and produces both adds and removes, with the removes either automatic for rule-derived access or routed to the new manager for a decision on anything that was requested individually. Then the honest part, which interviewers reward: say which categories you would not auto-remove, and why, and how the exceptions get an owner and an expiry rather than becoming permanent. Privilege creep is a recurring audit finding, and the mover event is where it is created.

The leaver is where speed is the control. The sequence matters and you should be able to recite it: disable rather than delete, so the audit trail and the data survive; revoke active sessions and refresh tokens, because disabling an account does not by itself invalidate a token already issued; remove group memberships and application assignments; reclaim licences, which is where you find the budget argument that makes leadership care; handle the mailbox, the home directory and the personal file storage per a retention rule somebody in legal has signed; rotate any shared secret that person knew; remove them from on-call, from the VPN, from the building, from the privileged vault and from every approval workflow where they are named as an approver. Then the one that catches teams out: check what they owned. A departing engineer is often the owner of service accounts, certificates, API keys, scheduled jobs and application registrations, and an unowned privileged credential is worse than an active one.

The measurement is the part that turns experience into a resume line. Deprovisioning time, measured from the HR termination event to the last access removed, is the number governance hiring managers ask about, because it is the one the audit asks about. If you have ever reduced it, you have a resume bullet. The involuntary termination path is separate and should be described separately: a planned leaver can run on the overnight cycle, while a security-initiated termination has to run in minutes and usually needs a manual emergency runbook that you should be able to describe.

Around those three events sit the structures that make them work, and naming them correctly signals experience. Authoritative source and precedence rules, for when HR and the contractor register disagree. Correlation and matching logic, and what you do with the exceptions that match nothing. An entitlement catalogue with business-readable names, because an access request screen that offers a user the choice of CN=APP_FIN_GL_RW_P is a governance failure dressed as a technical one. Birthright versus requestable access. Role-based access control with roles that have named business owners, rather than roles mined from existing membership and never validated. Segregation of duties rules, with the classic examples being the person who can both create a vendor and approve a payment, or both write code and deploy it to production unreviewed. Access certification campaigns, and the brutal reality that managers approve everything in bulk unless you reduce the review to decisions they can actually make. Orphan and dormant account detection. Contractor records with mandatory end dates. If you can speak to six of those with a specific example each, you interview above your years.

• Name your authoritative source by product, not as 'HR'. Workday behaves differently from ADP and interviewers know it.
• Mover equals recalculate, not add. That one sentence is the difference between sounding experienced and sounding read-up.
• Disabling an account does not kill a live session. Know how you revoke tokens on your platform.
• Deprovisioning time from HR event to last access removed is the metric. Learn yours even if nobody has asked you for it.
• Check what the leaver owned: service accounts, certificates, API keys, approvals. Unowned privilege is the finding that recurs.
• Contractors and rehires are the two cases that expose whether you have run a lifecycle or only read about one.

Which platforms count, and which ones you cannot learn without a job

IAM hiring is unusually product-literal. A posting that says Okta means Okta, and a resume that says 'experience with leading IAM platforms' is read as no experience with any of them. The fix is not to claim more products. It is to pick a lane that matches the employers near you, go deep enough to discuss configuration details, and be honest about the rest.

Microsoft Entra ID is the highest-probability bet for most job seekers, for the unglamorous reason that most organisations already pay for it. If your employer runs Microsoft 365, you already have an estate to learn in. Depth here means more than knowing that conditional access exists: it means knowing how multiple policies combine and that a block wins, what report-only mode is for and why you stage every policy through it, the difference between security defaults and designed policy, how named locations and device filters behave, what Privileged Identity Management actually changes about role assignment, how Entra ID Governance delivers access reviews, lifecycle workflows and entitlement management, what Entra Connect or Cloud Sync does to on-premises objects and what happens when it stops, how app registrations differ from enterprise applications, the difference between delegated and application permissions on Microsoft Graph, how admin consent works and why user consent needs restricting, and how cross-tenant access settings govern guest collaboration. Learn Microsoft Graph and PowerShell alongside it, because Entra work at any scale is script work.

Okta is the other name that appears constantly, and it has the lowest barrier to practice of the major enterprise platforms because the developer tenant is free and generous. Depth means Universal Directory and profile mappings, application assignment through groups rather than individually, group rules, sign-on policies and authentication policies as distinct things, Okta FastPass and the device trust story, lifecycle management with inbound and outbound provisioning, Okta Workflows for the automation the product does not do natively, and Okta Identity Governance if the posting mentions access certification. Auth0, now sold as Okta Customer Identity Cloud, is the customer-identity sibling with its own free tier, its Actions model and its Organizations model.

Ping Identity shows up in large regulated enterprises, especially banks and insurers, often in long-lived deployments of PingFederate and PingDirectory with PingAccess in front of legacy applications, and increasingly PingOne Advanced Identity Cloud following the ForgeRock acquisition. Orchestration with DaVinci appears in newer work. These are not learnable at home in any realistic way, which is why Ping experience commands a premium and why consultancies are the usual route into it.

SailPoint and Saviynt are the governance platforms that dominate postings, and here is the part career guides skip: you cannot practise them at home. There is no free tier, no community edition and no realistic lab. That makes them gatekept skills, acquired almost exclusively on an employer's licence. There are three ways in and you should pick one deliberately. Join a company that already runs one and volunteer for the identity project, which is the cheapest route and the one most people miss. Join an implementation partner or consultancy, where you will be trained because they need billable engineers, and accept travel and client pressure in exchange for two years of concentrated experience. Or take a contract role at the analyst tier on a programme that needs hands, which in IAM is a genuinely common entry path rather than a consolation prize. Vendor training is worth paying for only when it comes with product access.

For privileged access, CyberArk is the name that appears most often in postings, and its certification ladder (Defender, then Sentry, then the senior engineering tier, under whatever the current naming is) is both a real filter and a real syllabus. Delinea Secret Server and BeyondTrust Password Safe appear in mid-market estates. HashiCorp Vault and Teleport belong to engineering-led organisations and look more like platform work than security work. In cloud estates, know AWS IAM Identity Center with permission sets, IAM Access Analyzer, service control policies and resource control policies, plus IAM Roles Anywhere and workload federation patterns; on Google Cloud, know the IAM policy hierarchy, conditions, Workload Identity Federation and the privileged access tooling; on Azure, know the split between Azure role-based access control for resources and Entra roles for the directory, because candidates conflate those two constantly.

Do not skip Active Directory because it is old. It is still the authoritative store for most large enterprises and it is where privilege escalation actually happens. Know the object model, groups and scopes, group policy, delegation, Kerberos including what a service principal name is, trusts, and the Active Directory Certificate Services attack family documented as ESC1 and onward, because a vulnerable certificate template is still one of the most reliable paths from a normal user to domain administrator. An IAM engineer who can explain why a template with a permissive subject-name setting is a domain-wide problem is noticeably more hireable than one who only knows cloud.

• Free and learnable at home: Okta developer tenant, Auth0 free tier, Keycloak, OpenLDAP or FreeIPA, an Active Directory lab, AWS and Google Cloud free tiers, Microsoft Entra ID in whatever tenant you can legitimately get.
• Gatekept, employer-only: SailPoint, Saviynt, CyberArk at production scale, Ping, Omada. Plan a route in rather than pretending.
• Pick one platform family and go three questions deep. Nine logos with one answer each is the commonest self-inflicted rejection in this field.
• Script it. PowerShell and Microsoft Graph for Entra, Python or Terraform for Okta, and any language for API-driven provisioning. Click-only candidates cap out at analyst.
• Learn Active Directory even if the job is cloud. Delegation, Kerberos and certificate templates still decide real escalations.

The protocols, and the depth you will actually be questioned to

Every IAM interview contains a protocol segment, and it is more forgiving than candidates fear and less forgiving than they prepare for. Nobody expects you to recite an XML schema. They expect you to trace a flow, say which party does what, and know where it breaks.

SAML 2.0 is still everywhere in enterprise single sign-on and will be for years. You should be able to draw the flow both ways: service-provider initiated, where the user hits the application first and is redirected with an authentication request, and identity-provider initiated, where the user starts from a portal tile and the application receives an unsolicited assertion. Know what is in the assertion: the issuer, the audience restriction that names the intended service provider, the subject and the NameID with its format, the conditions with their validity window, the attribute statement, and the signature. Know that the signature can cover the assertion, the response, or both, and that the service provider verifies it against a certificate it holds. Then know the failure modes, because that is what the troubleshooting question is: an expired signing certificate, which is the commonest cause of an application breaking overnight for everybody at once; clock skew making an assertion appear not yet valid or already expired; a mismatched audience or entity identifier after someone edited configuration; a NameID format change that makes every user look like a new user to the application; a relay state lost on the way through a proxy; and an assertion consumer service URL pointing at the wrong environment after a migration.

OAuth 2.0 and OpenID Connect are the modern pair and the distinction is tested constantly. OAuth 2.0 is a delegated authorization framework: it gets a client an access token to call a resource. OpenID Connect sits on top and adds authentication: it returns an ID token, a JWT describing who the user is, for the client itself to consume. The commonest wrong answer in interviews is treating an access token as proof of identity. Know the authorization code flow with PKCE as the default for essentially everything now, including browser and mobile applications; know why the implicit flow was deprecated; know client credentials for machine-to-machine; know device authorization for televisions and command-line tools, and know that the same device flow is actively abused in phishing campaigns that ask a victim to enter an attacker's code. Know what scopes are, what the audience and issuer claims are for, how a resource server validates a token signature against a published key set, what a refresh token is and what revoking one does and does not stop, and the difference between a bearer token that anybody holding it can replay and a sender-constrained token bound to a key or a client certificate. If you have read the token exchange and resource indicator specifications, say so when agent or service-to-service delegation comes up, because that is where they matter.

SCIM 2.0 is the provisioning protocol and governance roles ask about it directly. Know that it defines a schema for users and groups and a REST pattern for creating, updating, patching and deactivating them, that the deactivation signal is normally the active attribute rather than a delete, and that the gap between the specification and what vendors implement is where all the pain lives. Be ready for the practical question: an application supports SCIM, your users provision fine, but group membership does not sync. The answer involves checking whether the application implements group resources at all, whether you are pushing groups or the application is pulling them, how it matches on external identifier versus username, and whether patch operations are supported for member changes.

On the authentication side the centre of gravity has moved to phishing-resistant factors, and you should be able to argue the hierarchy. One-time passcodes over SMS are weak against interception and against carrier-level account takeover. Authenticator-app codes are better and still phishable, because a user will type a code into a convincing proxy. Push approval is better again and still defeated by fatigue attacks, which is why number matching and context display exist. FIDO2 and WebAuthn credentials, including passkeys, are phishing-resistant because the credential is bound to the origin, so a proxy cannot relay it. Know the distinction interviewers like: a device-bound passkey lives in one piece of hardware and cannot be copied, while a synced passkey is backed up to a platform account and is more convenient and less contained, and that distinction decides whether it is acceptable for administrators. Certificate-based authentication and Windows Hello for Business are the enterprise variants. For public-sector context, the US federal zero trust memorandum known as OMB M-22-09 directs agencies to enforce phishing-resistant multi-factor authentication for staff, which is why federal and contractor postings name it explicitly; check whether later guidance has superseded any specific requirement before you quote a deadline at an interviewer.

Two further areas separate strong candidates. The first is token theft and session security, the attack pattern of the moment: adversary-in-the-middle phishing kits capture the session cookie or token after a successful multi-factor authentication, so the attacker inherits an authenticated session without ever needing the second factor. The controls you should be able to name are phishing-resistant factors, device compliance or managed-device requirements in policy, token protection or binding where your platform supports it, continuous evaluation so that a revocation takes effect in minutes rather than at token expiry, shorter token lifetimes for high-risk applications, and detection on impossible travel and anomalous token use. The OpenID Foundation's Shared Signals Framework, and the Continuous Access Evaluation Profile built on it, are the standards answer to propagating a revocation between providers, and knowing they exist is a differentiator. The second is the identity attack catalogue: golden SAML, where an attacker who steals a federation signing key can mint assertions for anyone; consent phishing, where a user is tricked into granting a malicious application broad permissions on their data; service-desk social engineering, where the attacker simply calls and asks for a factor reset; and privilege escalation through Active Directory certificate templates. You are not applying for a penetration testing role, but every one of those is defended with an IAM control, and naming the attack and the control together is what makes an interviewer relax.

• Be able to draw SAML service-provider initiated and identity-provider initiated flows on a whiteboard in under two minutes.
• ID token for who the user is, access token for what the client may call. Confusing them is the fastest way to lose a protocol round.
• Authorization code with PKCE is the modern default. Know why implicit went away.
• Name the three or four reasons a SAML application breaks overnight. Expired signing certificate first.
• Know what revoking a refresh token does not stop, and how your platform shortens the window.
• Pair each attack with its control: adversary-in-the-middle with phishing-resistant factors and token binding, consent phishing with restricted user consent and an admin consent workflow, service-desk fraud with stronger verification at reset.

Getting in from help desk, sysadmin or security: the routes that actually work

IAM is one of the last security specialisms with a genuine internal ladder, and the reason is that the work is operational. Hiring managers know that the person who has processed four hundred access requests understands the mess better than a graduate with a certification. Your problem is not capability, it is vocabulary and evidence.

Route one, and the best one: convert the job you already have. If you work on a service desk, you are already doing identity work and describing it as tickets. Account creation is joiner provisioning. Group membership changes are entitlement assignment. Password and multi-factor resets are credential lifecycle, and the verification step before you perform one is an identity-proofing control. Leaver tickets are deprovisioning. Start by rewriting what you do in that vocabulary, then deliberately take on the three projects that convert a support resume into an IAM resume. First, the access review nobody wants to own: ask to run the next user access review for one application, and own the spreadsheet, the chasing, the removals and the evidence pack. Second, onboarding one application to single sign-on end to end, from the metadata exchange through the test users to the cutover communication. Third, an orphan and dormant account cleanup, which is self-contained, measurable, popular with auditors, and produces a number you can put on a resume. Any one of those three, done properly, is worth more at interview than a second certification.

Route two: the lateral move from systems administration. If you run Active Directory, group policy, Exchange or Entra ID, you are already two thirds of the way in. What you usually lack is the governance half: lifecycle design, access certification, segregation of duties, and the audit conversation. Close that gap by learning one governance product's concepts even without the product, by volunteering to be the technical contact for the next access audit, and by learning to script against Microsoft Graph or your platform's API so you arrive as an engineer rather than an administrator. Sysadmins usually enter at engineer level rather than analyst level, which is a meaningful salary difference, so do not undersell the infrastructure depth.

Route three: sideways from security. SOC analysts, GRC analysts and internal auditors all have a real route in, and each has a different gap. A SOC analyst knows the attacks and often not the lifecycle, so lead with detection of identity attacks and learn provisioning. A GRC analyst or auditor knows exactly what evidence an access review has to produce and often cannot build anything, so learn one platform hands-on and you become unusually valuable, because the person who can both configure the campaign and defend it to the auditor is rare. Pivoting from audit into governance engineering is one of the most reliable and least-discussed moves in this field.

Route four: implementation partners, consultancies and contract work. This is how many people get their first SailPoint, Saviynt, Ping or CyberArk experience, and it deserves to be said plainly rather than treated as a fallback. Systems integrators and identity specialist firms need billable engineers and will train people who show aptitude, because the licence and the client access are theirs to give. The trade is real: travel, utilisation targets, client deadlines, and sometimes a narrow slice of a product rather than ownership of a whole estate. Two years there buys you a product skill the open market will not let you learn any other way. Contract-to-hire is also unusually common in IAM programmes, because deployments are projects with funding cycles, so a six-month contract is not the warning sign it would be in some fields. Take it, document everything you build, and convert it into a permanent seat somewhere.

Route five, for people with no IT job at all: this is the hardest start and it is not impossible. The realistic entry title is IAM analyst, identity administrator, access administrator, or service desk with an identity focus, often inside a large bank, hospital group, university or government department where the identity team is big enough to have a junior tier. Search those titles rather than engineer. Build the lab described in the next section, take SC-300 or the Okta administrator track, and apply to organisations large enough to run a formal access management function. Plan on a year of deliberate work rather than a month, and treat the lab as the thing that gets you through the first conversation.

One thing worth saying about timing: inside a company, moving into the identity team typically takes a year or so of deliberate positioning, and it is dramatically easier than moving between companies into a role you have never held. If your employer has an IAM team, your fastest route to an IAM job is almost certainly the one down the corridor. Ask the team lead what they are short of, and volunteer for that specific thing rather than asking in general terms.

• Rewrite what you already do in identity vocabulary before you rewrite anything else. Most support staff are underselling real lifecycle experience.
• Volunteer for the access review, the single sign-on onboarding, or the orphan account cleanup. One of these beats a second certification.
• Search for IAM analyst, identity administrator and access management administrator, not only engineer. The analyst tier is the real door.
• Implementation partners and contract roles are the standard route to SailPoint, Saviynt, Ping and CyberArk experience. Treat them as a deliberate step, not a consolation.
• Auditors and HRIS analysts have a shorter path into governance than they think, because they already understand the evidence and the source data.

The lab and the artefacts that get you interviews

IAM rewards demonstrable work more than most security specialisms, because so much of it is configuration and because an interviewer can test your claim in two questions. The goal of a lab is not to look impressive. It is to give you first-person sentences: not 'SCIM provisions users', but 'when I tested patch operations on group membership against my own SCIM endpoint, the application accepted adds and silently dropped removes, and here is how I found it'.

Start with federation you built yourself, because it is free and it teaches the protocol properly. Create an Okta developer tenant, stand up Keycloak in a container, and register a simple application in both. Then federate them to each other. Configure the same application for SAML and for OpenID Connect and compare what arrives. Install a browser extension that decodes SAML assertions and read a real one field by field. Decode a JWT and identify the issuer, audience, subject, expiry and the key identifier that points at the signing key. Then deliberately break it: change the audience, let the certificate expire, skew the clock, change the NameID format, and write down the exact error each one produced. That error-to-cause table is the most useful page of notes you will own, because troubleshooting is what the technical round actually tests.

Then build an Active Directory lab, because the enterprise is still built on it. One domain controller, a couple of member servers, a handful of users, organisational units, group policy. Practise delegation. Set up Entra Connect or Cloud Sync to a tenant and watch what synchronises and what does not. Break the sync and recover it. Install Active Directory Certificate Services, read the published research on vulnerable template configurations, then create a vulnerable template in your own lab and understand why it is dangerous. If you want a prebuilt environment, the public deliberately-vulnerable Active Directory lab projects will save you a weekend, but build one by hand first.

Build one lifecycle end to end, even in miniature. Use a spreadsheet or a small database as your pretend HR system. Write a script that reads it and provisions accounts: creates the identity, derives a username, assigns birthright groups by department, and handles a change of department by recalculating rather than adding. Then write the leaver path, including session revocation. Microsoft Graph with PowerShell or Python against a tenant you control is the easiest version of this, and the Okta API is equally good. This single project gives you the lifecycle narrative the governance interview is built around, and almost nobody applying at analyst level has done it.

Write identity configuration as code. Terraform has mature providers for Okta and for Entra ID, and configuration-as-code for conditional access policies is an increasingly common requirement in mature shops. A small repository with a module that creates an application, assigns it to a group and applies a sign-on policy, with a pull request history showing you iterating, is a disproportionately strong artefact because it signals you will not be a click-only engineer. Add a pipeline step that validates policy changes before they apply and you are describing something many employers want and do not have.

Then write two short documents, because governance is partly a writing job and nobody expects a candidate to prove it. The first is a one-page joiner-mover-leaver design for an imaginary 2,000-person company: authoritative source, correlation rule, birthright matrix, provisioning targets and method per target, mover recalculation logic, leaver sequence with timings, and the three exceptions you decided to handle manually and why. The second is an access review design: which population, which entitlements, who reviews, what the reviewer sees, what happens to a revocation, how you evidence completion, and what you would change to stop managers approving in bulk. Both are short, both are specific, and both let you say that you have thought about this properly with something in your hand.

Publish what you can, privately if needed. A tidy public repository with the scripts, the Terraform, the error-to-cause table and the two design documents, plus two or three short write-ups of things you broke and fixed, is enough. Do not publish anything from an employer's tenant, do not screenshot real user data, and do not put a client name in a public repository. Redacted and generic is fine; indiscreet is disqualifying in a field whose entire subject is access control.

• Okta developer tenant plus Keycloak plus one sample application: free, and it teaches SAML and OIDC properly.
• Keep an error-to-cause table from deliberately broken federations. It is the best interview preparation document in this field.
• One miniature lifecycle, scripted from a fake HR source to a real tenant, buys you the narrative the governance interview is built on.
• Terraform for Okta or Entra, plus a validation step in a pipeline, separates you from click-only candidates.
• Two written documents: a JML design and an access review design. One page each. Specific.
• Never publish anything from a real tenant. Redact it, genericise it, or keep it private and describe it verbally.

The resume an IAM hiring manager actually reads

Two people read it and they want different things. A recruiter spends perhaps fifteen seconds confirming that the product named in the posting appears near the top and that your years are in range. The hiring manager, usually the identity team lead, reads it properly and is looking for scale, ownership and evidence you have operated rather than observed. Write for both by putting the platforms and the scale in the first three lines and the evidence in the bullets.

Lead with the estate, in units. 'Identity engineering for 14,000 workforce identities and 230 applications across Entra ID and Okta, with Workday as the authoritative source' places you immediately and is worth more than any summary paragraph. The units that mean something in this field are identities under management, split between employees, contractors and non-human accounts; applications integrated with single sign-on and what share of the total that is; directories and domains; privileged accounts vaulted; access requests and reviews per cycle; and lifecycle events per month. They are verifiable in conversation, which is exactly why they work.

Then write bullets as decisions with consequences, not duties. The shape that lands is what you built, what it replaced, what changed, and what it cost. 'Rebuilt the leaver path so terminations from Workday triggered account disable, token revocation and licence reclaim in the same run, cutting time from HR event to last access removed from 36 hours to under 1 hour, with a manual emergency runbook retained for security-initiated terminations.' That bullet contains a system, a mechanism, a number and an honest caveat, and a manager who has done the work believes every clause. Compare it with 'responsible for user deprovisioning', which says nothing.

Name the components, not just the suite. 'Entra ID' is a keyword. 'Entra ID with Conditional Access, Privileged Identity Management, entitlement management, access reviews, Entra Connect, app registrations and Graph automation' is a map of what you have touched, and it is also what the applicant tracking system matches. Do the same for Okta (Universal Directory, authentication policies, lifecycle management, Workflows, Identity Governance), for SailPoint (connectors, identity profiles, roles and access profiles, certification campaigns, provisioning policies, and whichever rule language that deployment used), for Saviynt, and for CyberArk (vault, central policy manager, privileged session manager, safes and platforms).

Put the numbers that auditors and managers both care about where they can be seen: deprovisioning time, share of applications on single sign-on, multi-factor coverage and which factors, privileged accounts vaulted and standing admin rights removed, access review completion rate and cycle duration, orphan accounts eliminated, password reset tickets reduced, and audit findings closed. If you have closed a repeat audit finding, say which one in generic terms; that is the single most persuasive line available to a governance candidate.

Keep the file machine-readable. One column, no text boxes, no skills rendered as a graphic, consistent date formats, PDF unless the posting asks otherwise. Parsers drop what they cannot read, and a two-column layout is the usual reason a strong resume reaches the recruiter with half its experience section missing. Put certifications on one line near the bottom with years. They are filter tokens, not achievements, and a badge wall at the top makes a manager assume the content below is thin.

What gets ignored, or counts against you: a table of twenty product logos with one line of substance behind them; 'passionate about cybersecurity'; claiming SailPoint and Saviynt and Okta and Ping and CyberArk at equal depth, which collapses the moment the interviewer picks one; ticket counts with no outcome, because 'processed 5,000 access requests' invites the question of whether anything improved; listing frameworks you have 'exposure to'; and any phrasing that hides whether you built something or watched someone build it. 'Supported the implementation of' is read as 'was in the room'. If you were in the room, say what you personally did in it.

If you are converting from support or sysadmin work, keep your real job titles and let the bullets do the arguing. Do not invent an IAM engineer title you did not hold; identity people check, and getting caught on a title in a field about verified trust is unrecoverable. Instead, group the identity work under a clear sub-heading inside your real role so a skim-reader sees it immediately.

• First three lines: platforms, identity count, application count, authoritative source. Scale before adjectives.
• Four to six bullets per role, each with a system, a mechanism and a number.
• Name components, not suites. The component list is what both the manager and the parser read.
• Lead with the metrics that appear in audits: deprovisioning time, single sign-on coverage, standing privilege removed, review completion.
• One line for certifications, at the bottom, with years. No badge wall.
• Two pages, one column, PDF. Say what you personally built, never 'supported the implementation of'.

How hiring runs, what the interview tests, and where the market is in 2026-27

Who screens you depends on where the team sits. In most mid-size and large organisations the first real conversation is with the IAM team lead or manager, inside either the security organisation or IT infrastructure, and that person probes lifecycle and troubleshooting rather than theory. In consultancies and implementation partners the screen is often a practice lead, and the emphasis shifts to client-facing ability, delivery experience and which product versions you have deployed. In regulated industries an internal auditor or a compliance lead frequently joins a later round, and candidates underprepare for that conversation badly. In engineering-led companies identity may live inside a platform team, and the interview will look more like a software interview, with scripting and infrastructure-as-code expected.

The stages are usually these. A recruiter screen of 20 to 30 minutes, almost entirely a keyword and years check plus salary and location. A hiring-manager call of 45 to 60 minutes where you will be asked to describe an estate you have worked in and walk through a lifecycle. A technical interview of 45 to 75 minutes, often with two engineers, covering protocols, a troubleshooting scenario and a design question. A practical element in perhaps half of processes: a task in a sandbox tenant, a short take-home, a script review, or a whiteboard of a joiner-mover-leaver flow. A final stakeholder round with audit, an application owner or an operations lead. Two to five weeks end to end for permanent roles, and a week or less through staffing firms. Government and defence roles add clearance after the offer, measured in months, and a clearance you already hold is a very large advantage in that segment.

The technical round reliably tests four things. First, protocol fluency to the depth described earlier: trace a flow, name the tokens, say who validates what. Second, troubleshooting method. You will be given a vague failure, usually that users cannot log in to one application since this morning, and the interviewer is watching whether you narrow before you guess. Ask which users and whether it is all of them, which application and whether others are affected, whether it is a new integration or an existing one, whether it fails before or after the identity provider, what the error on screen actually says, what the sign-in logs show, and what changed in the last day. Then propose the two or three likeliest causes in order of probability. Candidates who immediately start naming settings lose this question even when they happen to name the right one. Third, lifecycle design: given a company with an HR system, a set of applications and a compliance requirement, design the joiner, mover and leaver flows and defend your choices about what to automate and what to route for approval. Fourth, judgement under conflicting pressure, which is the question that separates engineers from administrators: an executive wants an exception to a policy, a project needs an application live on Friday without single sign-on, a team wants a shared service account with broad rights. What do you do. The answer that works is neither refusal nor compliance. It is a time-bounded exception with a named owner, a compensating control, a written expiry and a route back to the standard, because that is what the job actually is.

The audit conversation, if there is one, tests whether you can produce evidence rather than opinion. Expect questions about how you would prove that every leaver last quarter lost access, how you would demonstrate that an access review actually happened, what you would do about an application that cannot support single sign-on or automated deprovisioning, and how you handle a segregation of duties conflict that the business insists it needs. Answer with artefacts: a report, a log, a signed campaign record, a compensating control with a monitoring rule attached. Governance hiring managers are hunting for the candidate who understands that an undocumented control is, for their purposes, not a control.

On the market shape: demand has held up better in identity than in several other security specialisms, for reasons that are structural rather than fashionable. Identity is where most real intrusions now begin, so it keeps budget. Audit and regulatory pressure in finance, healthcare and the public sector creates work that cannot be deferred indefinitely. Mergers and divestitures create identity projects by definition, since two directories must become one or one must become two. Migration work continues steadily: on-premises directories and legacy federation products to cloud identity, legacy governance deployments to their software-as-a-service successors, and password-based authentication to passkeys. And the non-human identity problem described in the next section is creating headcount under new names. The flip side is honest too: pure administrator seats, the ones that are a ticket queue and a console, are the most exposed to both outsourcing and automation, which is the practical argument for learning to script and to deploy configuration as code rather than staying click-only.

Titles to search, because this field hides behind many: IAM engineer, identity engineer, identity and access management analyst, IGA engineer, identity governance engineer, access management engineer, PAM engineer, privileged access engineer, directory services engineer, identity platform engineer, Okta administrator, Entra ID engineer, SailPoint developer or engineer, Saviynt engineer, CIAM engineer, identity architect. The same job is advertised under at least four of those, and the pay attached to each varies more than the work does.

On pay, use sources rather than rumours. There is no BLS occupation for this role; Information Security Analysts (SOC 15-1212) and Network and Computer Systems Administrators (SOC 15-1244) in the Occupational Employment and Wage Statistics bracket it, and the real seat usually pays above the administrator series and at or above the analyst series depending on specialism and region. Governance and privileged access specialisms tend to pay above general access management, consultancy pays above internal IT for the same experience in exchange for travel and utilisation, and contract rates in IAM programmes are often well above the permanent equivalent without benefits. Read live postings in pay-transparency states for the band, compare like for like, and ask the recruiter on the first call.

• Narrow before you guess. The troubleshooting question is a test of method, not of recall.
• Have one lifecycle you can narrate for ten minutes without notes, with the system names in order.
• For the exception question, answer with a time-bounded exception, a named owner, a compensating control and an expiry. Never pure refusal, never pure compliance.
• Prepare the audit round specifically: how you would evidence that a control ran, not just that it exists.
• Search at least six title variants. The same job is posted as engineer, analyst, administrator and developer at different pay.
• Ask the band on the first recruiter call, and compare permanent against contract separately.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Identity and Access Management (IAM)
• IAM engineer
• IAM analyst
• Identity engineer
• Identity administrator
• Identity governance and administration (IGA)
• IGA engineer
• Access management
• Privileged access management (PAM)
• Customer identity and access management (CIAM)
• Joiner-mover-leaver (JML)
• Identity lifecycle management
• Provisioning and deprovisioning
• Birthright access
• Entitlement management
• Access certification
• User access review (UAR)
• Recertification
• Segregation of duties (SoD)
• Role-based access control (RBAC)
• Attribute-based access control (ABAC)
• Role mining
• Least privilege
• Zero trust
• Single sign-on (SSO)
• Multi-factor authentication (MFA)
• Phishing-resistant MFA
• Passwordless authentication
• Passkeys
• FIDO2
• WebAuthn
• SAML 2.0
• OAuth 2.0
• OpenID Connect (OIDC)
• SCIM 2.0
• LDAP
• Kerberos
• JWT
• PKCE
• Token revocation
• Conditional Access
• Continuous access evaluation
• Shared Signals Framework
• Microsoft Entra ID
• Azure Active Directory
• Entra ID Governance
• Privileged Identity Management (PIM)
• Entra Connect
• Microsoft Graph API
• PowerShell
• SC-300
• Okta
• Okta Workflows
• Okta Identity Governance
• Okta Lifecycle Management
• Auth0
• Ping Identity
• PingFederate
• PingDirectory
• PingOne Advanced Identity Cloud
• ForgeRock
• Keycloak
• SailPoint IdentityIQ
• SailPoint Identity Security Cloud
• Saviynt
• Omada
• One Identity
• CyberArk
• Delinea
• BeyondTrust
• HashiCorp Vault
• Active Directory
• Group Policy
• Active Directory Certificate Services
• AWS IAM Identity Center
• AWS IAM
• Google Cloud IAM
• Workload Identity Federation
• Azure RBAC
• Service accounts
• Non-human identity (NHI)
• Machine identity
• Secrets management
• Workday
• SuccessFactors
• ServiceNow
• Terraform
• Identity as code
• SOX ITGC
• PCI DSS
• HIPAA
• ISO 27001
• Access request workflow
• Break-glass account
• Just-in-time access
• Golden SAML
• OAuth consent phishing
• Adversary-in-the-middle (AiTM)
• Identity threat detection and response (ITDR)
• Identity security posture management (ISPM)
• Agent identity
• Model Context Protocol (MCP)
• CIDPRO
• DoD 8140

Mistakes that cost people this job

Questions people ask