Study ISC2 CISSP Authentication and MFA: key concepts, common traps, and exam decision cues.
On this page
The first IAM lesson asks a simple question with major consequences: how sure are you that the subject is who they claim to be? CISSP wants clean thinking across proofing, authentication factors, and trust between identity providers and relying systems.
Identity-choice map
Requirement
Better first instinct
reduce account-takeover risk
MFA with strong factor design
let one trusted identity system authenticate to another service
federation and SSO
establish confidence before issuing credentials
identity proofing and registration controls
avoid repeated passwords across many services
centralized authentication or SSO pattern
What the exam is really testing
If the stem says…
Strong reading
“user is legitimate but login is weak”
strengthen authentication, not authorization
“one organization trusts another for login”
federation and trust assertions matter
“new identity issuance”
proofing and enrollment quality matter before MFA even starts
Decision order that usually wins
Ask whether the problem is proofing, authentication, or delegated trust.
Confirm how the identity was established before the login event.
Choose the authentication strength needed for the risk.
If one system trusts another, focus on federation assertions and trust relationships.
Only then optimize for convenience with SSO or reduced password repetition.
The exam wants clean separation between identity issuance and login strength. Strong MFA does not rescue a weak enrollment process, and SSO does not replace careful trust design.
Scenario triage
Scenario
Better first move
new users receive credentials with weak vetting
improve identity proofing and registration
login compromise risk is rising
strengthen MFA and factor independence
many apps need one central login experience
use centralized authentication or federation
one company wants another to authenticate its users
rely on federation trust and assertions
users complain about repeated passwords
consider SSO after trust and assurance requirements are clear
Common traps
Trap
Better rule
treating SSO as automatically more secure
SSO improves usability, but trust concentration still must be protected
mixing OAuth, OIDC, SAML, and Kerberos as if they solve the same problem
classify the protocol family by what it asserts or delegates
assuming MFA fixes poor identity proofing
weak enrollment undermines later authentication strength