Domain 5 · Objective reference 5.2 · Chapter 33 of 62
Design identity proofing and authentication
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Proofing establishes a person; authentication tests a claim.
Explore the anchors
Establish identity at enrollment.
Concept matching activity
Match this task or description to its concept:
Bind an authenticator to the identity.
Choose a concept before checking the explanation.
Access-decision sandbox
Try to edit a fictional record as a reader. Then change one condition and evaluate again. This simplified policy requires authentication, object scope and action permission; real policies have more conditions.
Change the request, then evaluate it.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
- Proofing, credentials and session boundaries
Concepts and mechanisms
Identity proofing establishes an association with a person or entity; enrollment binds credentials or authenticators; authentication evaluates a later claim. Factors include knowledge, possession and inherence, and two knowledge secrets are not different factor types. Device and workload identities also need trustworthy establishment and lifecycle management. Account recovery can undermine the original authentication strength if its verification is weaker.
Design, evidence and tradeoffs
Choose assurance appropriate to the resource and consequence. Evaluate passwordless approaches, multi-factor authentication, credential vaults, session management and just-in-time privilege as different design elements. Single sign-on simplifies use but concentrates identity availability and trust. Federation requires valid issuer, audience, signature, expiry and policy handling; authorization still belongs to the relying service. Behavioral signals can inform a decision but can be wrong and need an appropriate response path.
Proofing, credentials and session boundaries
Identity proofing establishes confidence in an identity claim before issuing credentials; authentication checks a later claim. MFA combines distinct factor categories, while two passwords do not make two factors. Passwordless methods can use cryptographic authenticators, but implementation, recovery and enrollment determine their properties. Protect vault access, enrollment, revocation and service credentials. A secure authentication event does not automatically secure a stolen session: limit session scope, protect tokens, reauthenticate sensitive changes and invalidate sessions when justified. Just-in-time access limits when privileges exist; it does not remove the need for approval and accountability.
Worked example
A help desk does not reset a privileged account merely because a caller knows public personal details.
Check your understanding
What does authentication not determine by itself?
Show explanation
It does not establish that the identity may perform every requested action on every resource.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.