What changed

Every content update is versioned. Select a version to compare it with the one before.

Version 7 → 8

Update

Two new sections: how MFA fatigue and relayed codes work and why passkeys resist both, and what makes an account privileged, with standing privilege compared to just-in-time access.

3 lessons updatedduration

Content update. Enrolled learners were notified.

Duration changed from 17 to 21 minutes.

Authentication vs authorization, and MFA factors

Two questions sit at the heart of every access decision: 1. **Authentication (AuthN)**: *Who are you?* The system verifies that the person or service really controls the account. 2. **Authorization (AuthZ)**: *What are you allowed to do?* Once identity is proven, policies, roles and permissions decide which applications, data and actions are permitted. A user can be perfectly authenticated and still not be authorized to open the payroll system. Keep the two steps separate in your thinking. ::diagram isf-authn-authz ### Multi-factor authentication MFA combines factors from different categories so that one stolen secret is not enough: - **Something you know**: a password, a PIN, a security question. - **Something you have**: a phone receiving a push notification, an authenticator app generating TOTP codes, a FIDO2 security key. - **Something you are**: a fingerprint or face scan, usually unlocking a device or a passkey. Not all factors are equally strong. SMS and email codes can be intercepted or phished. Push approvals can be abused through "MFA fatigue" attacks. **Passkeys (FIDO2/WebAuthn)** are bound to the real website and resist phishing, which is why many organizations now treat them as the preferred factor. ### Two attacks on the second factor, and why passkeys hold **MFA fatigue.** The attacker already has the password, for example from a phishing page. Every sign-in attempt sends a push prompt to the victim's phone. The attacker repeats it, often late at night, until the tired user taps Approve just to make it stop. Nothing was broken technically: the user was worn down. **Relayed codes.** A fake sign-in page asks for the password and the one-time code, and passes both to the real site within seconds. This works for SMS, e-mail and authenticator app codes alike, because a code is valid wherever it is typed. A **passkey** closes both gaps. It is a key pair: the private key never leaves the user's device, and the device answers a sign-in challenge only for the website address (the origin) the passkey was registered for. A look-alike site has a different address, so it receives nothing it can reuse. There is no prompt to approve by reflex and no code to pass on. A passkey is also **passwordless**: the user unlocks it with a fingerprint, a face scan or the device PIN, and no password is typed or kept on the server. | Factor | A stolen password is not enough | Holds against a fake sign-in page | | --- | --- | --- | | SMS or e-mail code | Yes | No, the code can be relayed | | Authenticator app code | Yes | No, the code can be relayed | | Push approval | Yes | No, and repeated prompts can wear the user down | | Passkey (FIDO2/WebAuthn) | Yes | Yes, it is bound to the real site | > Tip: Ask whether a factor is phishing-resistant, not only whether MFA is "on".

Identity vocabulary

The text changed in other languages only.

IAM, PAM and IGA

Identity security is usually split into three disciplines. They overlap, and mature programmes run them together. - **IAM (Identity and Access Management)** controls everyday access: single sign-on, MFA, directories, user lifecycle and access policies. Its goal is that the right people reach the right applications with as little friction as possible. - **PAM (Privileged Access Management)** protects the small set of accounts that can do the most damage: domain admins, root, database owners, cloud administrators. Typical controls are a credential vault, password rotation, approved sessions and session recording. - **IGA (Identity Governance and Administration)** answers *should* this access exist? It covers access requests and approvals, periodic access reviews (certifications), segregation of duties and audit evidence. A simple way to remember it: IAM opens the door, PAM guards the vault room, and IGA checks the guest list regularly. In the Monofor suite, **Monosign** brings access management and governance together in one platform, **Monopam** focuses on privileged access, and **Monosync** synchronizes identity data between sources and targets. Users of Monopam and Monosync normally sign in through Monosign, so it acts as the central identity. ::diagram isf-iam-pam-iga ### What makes an account privileged An account is privileged because of **what it can change**, not because of who uses it. A domain administrator is the obvious example. A service account that a backup tool uses with administrator rights on every server is just as powerful, and it is easier to overlook: no person signs in with it, its password rarely changes and nobody feels responsible for it. When you list privileged accounts with a customer, ask for both kinds: the ones people use and the ones machines use. ### Standing privilege and just-in-time access **Standing privilege** means the powerful access is there all the time, whether or not anyone is using it. Every hour it exists is an hour an attacker can use it. **Just-in-time access** removes that: the person asks for the access when a task needs it, it is granted for a limited time window, and it ends by itself afterwards. Example: a database administrator needs production access for a schema change on Thursday evening. | | Standing privilege | Just-in-time access | | --- | --- | --- | | When she holds the access | All year | Thursday 20:00 to 22:00 | | Who decided | Whoever set it up long ago | A colleague who approved this request | | What an attacker finds on Friday | A working administrator account | Nothing to use | > Tip: Start with IAM coverage, then protect privileged accounts, then add governance. Gaps in any of the three become attack paths.