9.2 MFA, Password Policy, SSO, and Federation

Authentication Factors and MFA

A single password is one knowledge factor. If it is reused, guessed, phished, or breached elsewhere, an attacker can sign in. Multi-factor authentication (MFA) requires proof from two or more different factor categories, so a stolen password alone is not enough.

The exam tests the five factor families and a critical trap:

The single most-tested point: a password and a second password (or a PIN and a security question) is single-factor, because both are knowledge. A password plus a hardware key is true MFA.

MFA methods are not equal. A phishing-resistant FIDO2 hardware key beats SMS one-time codes, because SMS is exposed to SIM-swap, interception, and social engineering. Push approvals are convenient but vulnerable to MFA fatigue (prompt bombing), where a user is nagged into approving an attacker's login. A beginner rule: require MFA for remote access, privileged access, financial systems, email, and identity administration, then match the method's strength to the risk.

Password Policy, SSO, and Federation

Modern guidance (NIST Special Publication 800-63B) reshaped password rules. Favor length over complexity: allow long passphrases, support all printable characters and spaces, accept at least 64 characters, screen new passwords against breached-password lists, and stop forcing periodic rotation unless there is evidence of compromise. Frequent forced changes push users to predictable patterns like Spring2026! then Summer2026!. Password managers help users keep a unique secret per service.

Single sign-on (SSO) lets a user authenticate once at a central identity provider (IdP) and then reach many applications without re-entering credentials. The security payoff is centralization: one place to enforce MFA, apply conditional access, disable a leaver, and monitor sign-ins. Without SSO, every application carries its own account store, password policy, and offboarding gap.

Federation across trust boundaries

Federation extends trust between organizations or domains. A relying party (also called a service provider) trusts an IdP to authenticate the user and send identity assertions or claims — it never receives the user's password. Know three technologies at awareness level:

• SAML 2.0 — XML assertions, common for enterprise web SSO.
• OAuth 2.0 — delegated authorization (granting an app scoped access to resources).
• OpenID Connect (OIDC) — an identity layer built on OAuth 2.0 that adds authentication.

Choosing the right answer

• Too many passwords, inconsistent enforcement, painful offboarding → SSO.
• Must trust identities issued by another organization or cloud IdP → federation.
• A password alone is too weak for the risk → MFA.
• Users pick weak or reused passwords → password policy + manager + breach screening + MFA.

A payroll-migration example shows the contrast: the weak path creates local payroll accounts and another password to remember; the strong path integrates payroll with the corporate IdP, enforces MFA, maps payroll roles to job duties, and auto-disables access at termination. The IdP authenticates; the payroll app still makes its own authorization decisions inside the application.

Account Management and Authentication Pitfalls

Authentication strength also depends on operational hygiene around the credential, not just the factor type. The exam expects you to recognize several supporting concepts. Account lockout temporarily disables a login after a threshold of failed attempts (for example, lock for 15 minutes after 5 failures) to slow online password guessing and brute-force attacks. Throttling and rate limiting achieve a similar goal without permanently locking a legitimate user out. A CAPTCHA raises the cost of automated attempts. These defend the front door even when the password itself is weak.

Secure password recovery is a frequent weak point. A reset workflow that relies only on easily researched security questions (mother's maiden name, first pet) can be socially engineered, so stronger designs send a one-time link to a verified channel and re-prompt for MFA. Help-desk-initiated resets must verify the caller's identity before acting — voice alone is not proof.

Biometrics: FAR, FRR, and CER

Biometric (inherence) systems are tuned, not perfect, and CC introduces three error rates:

When comparing two biometric readers, the one with the lower CER is more accurate overall. Tightening sensitivity lowers FAR but raises FRR, and vice versa — a classic security-versus-usability tradeoff.

SSO tradeoffs

SSO is not free of risk. Centralizing authentication concentrates value: if the IdP or a user's single credential is compromised, the attacker may reach every connected app — a "keys to the kingdom" exposure. That is precisely why SSO accounts, especially privileged ones, demand phishing-resistant MFA and close monitoring. The CC answer is rarely "avoid SSO"; it is "adopt SSO and protect the IdP and its identities accordingly."