What is identity and access management?
Short answerMaking sure the right people and systems have the right access, and being able to prove it.
Identity and access management, usually shortened to IAM, is the discipline of making sure the right people and systems can reach the right resources, at the right time, for the right reasons, and that you can show who had access to what.
In practice it covers four jobs. Identity: a single, trustworthy record of every person and service account. Authentication: proving someone is who they claim to be. Authorisation: deciding what they're allowed to do once they're in. Governance: reviewing and evidencing that access over time, so it doesn't quietly pile up.
Most organisations run this through an identity platform such as Okta or Microsoft Entra ID, which becomes the front door to every application.
What's the difference between authentication and authorisation?
Short answerAuthentication proves who you are. Authorisation decides what you can do.
Authentication answers "who are you?" Authorisation answers "what are you allowed to do?"
Showing your passport at an airport is authentication. Your boarding pass, which lets you onto one specific flight and not the others, is authorisation. The two are often handled by different systems: your identity provider authenticates you, then the application decides what your role lets you see and change.
Most breaches involving identity exploit one or the other: stolen credentials beat weak authentication, and excessive permissions turn a single compromised account into a much bigger problem.
What is single sign-on, and is it a security risk?
Short answerOne sign-in for all your apps. Done well, it's more secure than separate passwords, not less.
Single sign-on (SSO) lets people sign in once, to their identity provider, and then reach all their connected applications without separate passwords for each.
A common worry is that SSO puts all your eggs in one basket. It does, but that basket is far easier to protect than dozens of scattered passwords. With SSO you enforce strong MFA in one place, see every sign-in in one log, and switch off someone's access to everything in a single step when they leave. Without it, people reuse passwords across apps, and offboarding means hunting through each system by hand.
The key is to treat the identity provider as your most critical system: strong MFA for everyone, extra protection for administrators, and monitoring of unusual sign-ins.
Is SMS-based MFA good enough?
Short answerBetter than nothing, but it's the weakest form of MFA. Aim for phishing-resistant methods.
It's much better than a password alone, but it's the weakest form of MFA and no longer enough for most organisations.
Text-message codes can be intercepted through SIM-swap fraud, where an attacker persuades a mobile carrier to move your number to their SIM. More commonly, users are simply tricked into typing the code into a convincing fake login page. Authenticator-app push notifications help, but they can be defeated by the same fake pages, or by "MFA fatigue" attacks that bombard someone with prompts until they tap approve.
If you're still on SMS, the practical path is: move everyone to an authenticator app with number matching, then move towards phishing-resistant methods, starting with administrators and other high-risk users.
What does "phishing-resistant" authentication mean?
Short answerSign-in methods that can't be replayed on a fake website, such as passkeys and FIDO2 keys.
Phishing-resistant authentication can't be passed along to a fake website, even if the user is fooled. The credential is cryptographically tied to the real site's address, so a look-alike page simply can't use it.
The main options are FIDO2 security keys, passkeys, platform authenticators such as Windows Hello for Business, and Okta FastPass when it's configured to be phishing-resistant. Smart cards also qualify. These methods are usually easier for users too: a fingerprint or face check replaces typing codes.
For most organisations, the sensible first step is phishing-resistant MFA for administrators, finance teams and executives, then extending it to everyone.
SAML or OIDC: which should I use?
Short answerUse what the app supports best. Prefer OIDC for new and mobile apps, SAML for mature enterprise integrations.
Both are standards that let an identity provider tell an application "this person has signed in, and here's who they are". They solve the same problem in different eras.
SAML 2.0 dates from the mid-2000s and exchanges XML documents through the browser. It's mature, widely supported by enterprise software, and still the default for many business applications. OpenID Connect (OIDC) is newer, built on OAuth 2.0, and uses lightweight JSON tokens. It's better suited to modern web apps, mobile apps and APIs.
| SAML 2.0 | OpenID Connect | |
|---|---|---|
| Introduced | 2005 | 2014 |
| Format | XML assertions | JSON Web Tokens |
| Built on | Its own standard | OAuth 2.0 |
| Best for | Established enterprise apps | Modern web, mobile and APIs |
| Choose it when | It's the vendor's more mature option | You're building new or going mobile |
My rule of thumb: use whatever the application supports well. If it offers both, choose OIDC for new builds and anything mobile, and SAML where it's the vendor's more mature option. One common confusion is worth clearing up: OAuth 2.0 on its own is for authorisation, granting an app access to something on your behalf. OIDC is the layer that adds authentication on top.
What is SCIM provisioning?
Short answerThe standard that lets your identity provider create, update and remove accounts in other apps automatically.
SCIM (System for Cross-domain Identity Management) is a standard way for your identity provider to create, update and remove user accounts inside other applications automatically.
SSO controls how people sign in; SCIM controls whether their account exists at all. Without it, someone in IT creates accounts by hand in each app, and deleting them when people leave is easy to forget. With SCIM, assigning someone an application in Okta or Entra creates their account there, a change of department updates it, and removing them from the application disables it.
When you evaluate new software, SCIM support is one of the most useful things to check for. It's often only available on higher pricing tiers, so ask early.
What is joiner-mover-leaver?
Short answerThe three moments when access must change: joining, moving roles and leaving.
Joiner-mover-leaver, or JML, describes the three moments in someone's working life when their access needs to change: when they join, when they move roles, and when they leave.
Joiners and leavers get most of the attention, but movers are where risk quietly builds up. People change teams and keep their old access "just in case", until years later they hold far more than their job needs. This is known as privilege creep.
The strongest setups drive JML from the HR system: HR records the change, and the identity platform grants, adjusts or removes access automatically, using tools such as Okta Workflows. Leavers are the most urgent case. Access should end on someone's last day, not whenever a ticket is eventually picked up.
RBAC or ABAC: how should access be assigned?
Short answerRoles for the broad strokes, attributes for sensitive decisions.
Role-based access control (RBAC) grants access by job role: everyone in the finance team gets the finance applications. It's simple to understand and to audit, but roles tend to multiply as every exception becomes a new role.
Attribute-based access control (ABAC) decides access from attributes about the person and the situation, such as department, location, device health or time of day. It's more flexible and scales better, but it's harder to reason about and to explain to auditors.
Most organisations do best with a blend: roles for the broad strokes, drawn from clean HR attributes, and attribute-based conditions for sensitive access, such as requiring a managed device or blocking sign-ins from unexpected countries.
What do least privilege and PAM mean in practice?
Short answerGive people only the access they need, and put extra controls around the most powerful accounts.
Least privilege means giving people only the access they need to do their job, and nothing more. It limits the damage if an account is compromised, and it's a requirement in most security frameworks.
Privileged access management (PAM) applies that principle to the most powerful accounts: administrators, service accounts and anything that can change security settings or reach sensitive data. Good PAM usually means admins use separate accounts for admin work, elevated access is granted just in time and expires automatically, privileged sessions are logged, and shared passwords are held in a vault rather than a spreadsheet.
A good first step costs nothing: list who holds administrator rights in your identity provider and key systems, and ask whether each of them still needs it.
Have a question that isn't here?
Send it over. If it comes up often, it may well become the next article.
Email albert@albertsunday.com