5.2 Identification & Authentication Strategy
5.2 Identification & Authentication Strategy
Identity and authentication answer one of the most important security questions:
How confidently can we determine who - or what - is requesting access?
A modern identity strategy must work not only for people, but also for devices, applications, services and automated workloads.
Identify
Establish a unique identity for the person, device or service.
WHO ARE YOU?Authenticate
Verify that the claimant legitimately controls that identity.
PROVE ITAuthorise & Record
Determine permitted access and maintain accountability.
WHAT CAN YOU DO?The Big Idea
Authentication should not begin with the question:
"Which MFA product should we buy?"
It should begin with understanding the identity, the resource being protected and the risk associated with incorrect authentication.
Identity Strategy
Establish → Authenticate → Authorise → Account → Manage
What This Objective Covers
Identity strategy must cover both human and non-human identities.
Organise identities so access can be managed at scale.
Authentication, Authorization and Accounting.
Select appropriate authentication mechanisms according to risk.
Maintain trust after authentication has completed.
Establish that the digital identity represents the intended entity.
Allow identity information to be trusted across security domains.
Securely issue, store, rotate, recover and revoke authenticators.
Authenticate once and use multiple authorised services.
Create or enable access when required rather than maintaining unnecessary standing access.
🪪 Identification vs Authentication Claim an identity - then prove the claim
The subject claims or presents an identity.
"I am user mateusz.o."
The system verifies that the claimant is entitled to use that identity.
"Prove that you really are mateusz.o."
Identification vs Authentication
🎯 Authentication vs Authorization Identity and permission are different decisions
A user successfully logs into an HR platform.
Authentication has succeeded.
The user can view their own payslips but cannot change another employee's salary.
That restriction is authorization.
Authorization asks: "What may that identity do?"
Authentication · Authorization · Accounting
Establish confidence that the claimant legitimately controls the identity.
WHO ARE YOU?
Determine which resources and actions the authenticated identity is permitted to use.
WHAT CAN YOU DO?
Record relevant activity so access can be monitored and attributed.
WHAT DID YOU DO?
AAA
Logs are far more useful when individual activity can be associated with unique identities rather than shared credentials.
People, Devices & Services
Identity is no longer synonymous with "employee username".
Employees, customers, contractors, administrators and partners.
Laptops, phones, servers, network devices and specialised systems.
Applications, APIs, workloads, containers, automation and cloud services.
Non-human identities can hold privileges just as powerful as human administrator accounts.
👤 Human Identity Strategy Unique, verifiable and appropriate to the user population
Key Questions
Authentication suitable for reading a public discussion forum may not be suitable for:
💻 Device Identity Authenticate the device separately from the person using it
Systems may need assurance about both:
Alice enters valid credentials from:
an unknown unmanaged laptop.
Her identity may be legitimate while the device is unsuitable for accessing a sensitive service.
Device Identity Can Use
User vs Device
🤖 Service & Workload Identity Machines must authenticate too
Applications and services often communicate without a human directly participating in each request.
Better Strategy
Embedded long-lived credentials can be difficult to rotate, identify and revoke safely.
Registration, Proofing & Enrollment
Authentication is only useful if the original digital identity was established correctly.
If an attacker successfully registers as another person, the authentication system may later authenticate the attacker's credentials perfectly - to the wrong real-world identity.
🕵️ Identity Proofing Establish that the applicant is who they claim to be
Identity proofing happens before routine authentication.
Collect appropriate evidence supporting the claimed identity.
Determine whether the evidence appears genuine and valid.
Establish that the evidence actually relates to the applicant.
Create or register the digital identity after appropriate proofing.
A bank creates an online identity for a new customer.
The bank must first have sufficient confidence that the person enrolling is genuinely the customer whose identity is being created.
Identity Establishment
Knowledge · Possession · Inherence
A secret known by the claimant.
KNOWLEDGE
An authenticator or device controlled by the claimant.
POSSESSION
A biometric characteristic associated with the claimant.
INHERENCE
Authentication Factors
Know · Have · Are
📍 Context & Risk Signals Useful authentication information beyond the classic factors
Authentication strategy can also consider contextual information.
A user normally authenticates:
from a managed laptop in London during normal working hours.
Minutes later, the same identity attempts a sensitive action from an unknown device in another country.
The system may require stronger authentication or block the request based on risk.
2️⃣ Multi-Factor Authentication - MFA Use independent authentication factors
MFA combines authentication factors from different categories.
Password + hardware security key.
Knowledge + possession.
Smart card + PIN.
Possession + knowledge.
Both are knowledge factors.
Multiple credentials of the same factor type do not create multi-factor authentication merely because two prompts are present.
MFA
⚠️ MFA Is Stronger - Not Magic Authentication controls still have attack surfaces
MFA can significantly increase authentication assurance, but its effectiveness depends on the authenticators and implementation.
Users may be tricked into interacting with fraudulent authentication flows.
Repeated authentication prompts may pressure a user into approving an illegitimate request.
An attacker may target an authenticated session rather than repeat the original authentication process.
A weak recovery process can undermine strong everyday authentication.
🔑 Passwordless Authentication Remove the traditional password from the authentication flow
Passwordless authentication uses an authenticator other than a traditional memorised password as the primary authentication mechanism.
A device holds a cryptographic credential.
The user activates the credential through an approved local mechanism, such as a biometric or PIN.
The traditional reusable website password is not required.
Removing passwords does not remove the need to prove control of an identity.
Whether an authentication event is multi-factor depends on the authenticator design and which independent factors are actually used.
Passwordless
👁️ Biometrics Something you are
Biometric Considerations
An unauthorised person is incorrectly accepted.
An authorised person is incorrectly rejected.
Biometric information can itself be sensitive personal information.
Biometric characteristics cannot be replaced as easily as a password or cryptographic key.
Their convenience does not remove privacy, spoofing and lifecycle considerations.
Manage Identity at Scale
Assigning permissions manually to every individual user becomes difficult to manage in large organisations.
Groups and roles allow access to be organised around common business requirements.
A collection of identities managed together.
Finance employees.
A set of responsibilities or permissions associated with a business or technical function.
Payment approver.
Groups vs Roles
🧩 Groups & Roles Need Governance Scalable access can also scale mistakes
Membership may grant more access than every member genuinely needs.
Complex inheritance can make effective permissions difficult to understand.
Creating too many narrowly defined roles can make IAM difficult to maintain.
Users may remain in groups after responsibilities change.
Authenticate Once - Access Multiple Authorised Services
Single Sign-On - SSO - allows a user to authenticate through a central identity mechanism and subsequently access multiple authorised services without repeatedly entering separate primary credentials.
Benefits
Risks
The central authentication infrastructure becomes a highly important security and availability dependency.
Reusing one password across many separate applications is not Single Sign-On.
🤝 Federated Identity Management - FIM Trust identity information across security domains
Federation allows one security domain to rely on identity information established by another trusted identity provider.
An organisation uses its corporate identity system to authenticate employees accessing an external SaaS platform.
The SaaS provider trusts the organisation's identity provider rather than creating a completely independent authentication process for every employee.
If the identity provider is compromised, systems relying on its assertions may also be affected.
Federation
Authentication Is Not the End of the Decision
After authentication succeeds, the system usually creates a session.
That session now represents the authenticated user or service.
🍪 Secure Session Management Protect the authenticated state
Session identifiers should not be easily guessed.
Session information should be protected from interception.
Inactive sessions should not necessarily remain authenticated indefinitely.
Long-lived sessions may require a maximum lifetime even when activity continues.
Logout should invalidate the authenticated session.
Particularly sensitive operations may justify renewed proof of identity.
A customer logs into online banking.
Ten minutes later they attempt to:
change the account's security settings.
The system may require additional authentication because the action carries greater risk than viewing an account balance.
Session Lifecycle
Authenticators Have a Lifecycle
Revocation and recovery are therefore just as important as initial issuance.
🗝️ Password & Credential Vaults Centralise protection of high-value secrets
Credential-management systems can securely store and control access to sensitive credentials.
Possible Capabilities
A privileged password is stored in:
a shared spreadsheet.
The credential can be stored centrally, released only to authorised identities and rotated according to policy.
Central protection improves control but also concentrates valuable authentication material.
🛟 Account & Credential Recovery The recovery process must not become an authentication bypass
Users lose credentials.
Devices fail.
Security keys disappear.
Authentication strategy therefore needs secure recovery procedures.
Normal login requires strong MFA.
Password reset requires only:
knowledge of the user's date of birth.
The weaker recovery mechanism can undermine the stronger login mechanism.
Create or Enable Access When It Is Needed
Just-in-Time approaches reduce unnecessary standing identities or privileges.
Account or privilege exists continuously.
Identity, account or elevated access becomes available when required by an approved event or request.
An employee signs into a SaaS platform for the first time. The platform receives a trusted identity assertion and creates the required local user representation automatically.
An administrator receives elevated production privilege only for the approved maintenance period.
Just-in-Time
Not Every Authentication Event Requires the Same Assurance
| Scenario | Relative Authentication Requirement |
|---|---|
| Read public information | Little or no authentication may be required |
| Employee collaboration portal | Authenticated organisational identity |
| Customer financial account | Stronger authentication appropriate |
| Production administration | High-assurance authentication and privileged controls |
| Cryptographic-key administration | Very strong assurance and additional safeguards |
Consider the impact of impersonation rather than applying identical authentication to every resource.
🎣 Authentication Threats Understand what the strategy is trying to resist
Trick a user into disclosing or using authentication information with an attacker-controlled system.
Use credentials exposed by another service against additional accounts.
Try a small number of common passwords against many identities.
Repeatedly attempt possible authenticator values.
Generate repeated authentication requests in the hope that the user eventually approves one.
Steal or misuse an already authenticated session.
Obtain passwords, keys, tokens or other authentication material.
Circumvent normal authentication through weak account recovery.
Strong authentication is not defined only by how many prompts appear on the screen.
🛡️ Phishing-Resistant Authentication Reduce reliance on secrets users can accidentally give away
Cryptographic authenticators can be designed so authentication is bound to the legitimate service rather than depending entirely on a user recognising a fraudulent login page.
A user can accidentally type the secret into a convincing fake login page.
The authenticator can participate in a protocol that is tied to the intended service, reducing the opportunity to reuse the authentication response elsewhere.
🧾 Accounting & Identity Logging Authentication should create useful accountability
Useful Events
Security detects an administrator changing firewall policy.
Individual identities and appropriate logs should help determine:
A log entry showing "admin" is less useful if fifty people know the same credential.
An Employee Accesses a Sensitive Application
Microservice A Calls Microservice B
Every service uses the same embedded username and password.
The credential never expires.
Each workload has its own identity.
Credentials are centrally managed or short-lived.
Each service receives only the permissions required.
One Identity Provider Is Compromised
An organisation uses central SSO for:
Central authentication provides major operational benefits.
However, compromise of that central identity infrastructure can affect many relying applications simultaneously.
SSO Trade-Off
🎓 CISSP Scenarios Identify the IAM concept
A user enters the username "alice".
Which activity?
Identification.
Alice proves control of the identity using an approved authenticator.
Which activity?
Authentication.
Alice is authenticated but cannot open the payroll administration function.
Which control denied access?
Authorization.
Logs record which administrator connected and what changes were performed.
Which AAA component?
Accounting.
A login requires a password and PIN.
Is this necessarily MFA?
No. Both are knowledge factors.
A login requires a password and hardware security key.
Which concept?
MFA using knowledge and possession factors.
A fingerprint is used as part of an authentication process.
Which factor type?
Something you are - inherence.
A smart card must be physically possessed.
Which factor category?
Something you have - possession.
A passkey replaces the user's traditional website password.
Which authentication strategy?
Passwordless authentication.
Management claims that passwordless means no authentication is taking place.
Is this correct?
No.
Authentication still takes place using a different authenticator.
Before creating an online banking identity, the bank validates evidence that the applicant is genuinely the claimed customer.
Which activity?
Identity proofing.
An attacker successfully registers an account in another person's identity.
Later, the attacker's MFA works perfectly.
Which part originally failed?
Identity proofing / enrollment.
Finance employees are placed into one collection for easier administration.
Which IAM construct?
Group.
Users assigned the "Payment Approver" function receive permissions required to approve payments.
Which concept?
Role.
Users authenticate once and then access several authorised corporate applications without entering separate credentials for each.
Which concept?
Single Sign-On - SSO.
Employees use exactly the same password separately on five unrelated applications.
Is this SSO?
No. It is password reuse.
A SaaS service accepts an identity assertion issued by the customer's corporate identity provider.
Which concept?
Federated Identity Management.
The organisation's identity provider is compromised, affecting several SaaS applications that trust it.
Which lesson?
Federation and SSO create important central trust dependencies.
An authenticated user steals another user's active web session identifier.
Which control area becomes relevant?
Session management.
An online banking session automatically expires after prolonged inactivity.
Which control?
Idle session timeout.
A customer is already logged in but must authenticate again before changing security settings.
Which concept?
Reauthentication for a sensitive action.
Privileged passwords are stored centrally, rotated and released only after approval.
Which technology?
Credential / password vault.
Everyday authentication requires strong MFA, but the help desk resets accounts after asking only for a date of birth.
Primary concern?
Weak recovery undermines strong authentication.
A SaaS account is created automatically when a federated employee accesses the application for the first time.
Which concept?
Just-in-Time provisioning.
An administrator receives privileged access only for an approved 60-minute maintenance task.
Which concept?
Just-in-Time privilege.
An application uses the same embedded password as every other service in the environment.
Primary concern?
Poor non-human identity and credential strategy.
Every microservice receives its own identity and short-lived credentials.
Which principle is improved?
Service authentication, least privilege and accountability.
A legitimate user attempts a high-risk action from an unknown device in an unusual country.
Which strategy may respond?
Adaptive / risk-based authentication.
An attacker repeatedly sends MFA approval notifications until a user accidentally approves one.
Which attack pattern?
MFA fatigue / push fatigue.
An organisation adopts cryptographic authentication designed to resist credential phishing.
Which strategic goal?
Phishing-resistant authentication.
An employee's authentication succeeds, but the device's certificate is not recognised.
What distinction?
User authentication and device authentication are separate.
A user changes department but remains in all previous access groups.
Primary risk?
Stale group membership and privilege accumulation.
Recognise the Clue Words
Claim Identity
Username / identity claim.
IdentificationProve Identity
Verify claimant.
AuthenticationWhat Can You Do?
Permission decision.
AuthorizationWhat Did You Do?
Record activity.
AccountingPassword / PIN
Secret knowledge.
Something You KnowSecurity Key / Smart Card
Physical authenticator.
Something You HaveFingerprint / Face
Biometric.
Something You AreTwo Different Factors
Stronger authentication.
MFANo Traditional Password
Cryptographic authenticator.
PasswordlessVerify Person Before Enrollment
Establish real identity.
Identity ProofingUsers Collected Together
Administrative grouping.
GroupBusiness Function
Permissions aligned to responsibility.
RoleLogin Once
Access multiple authorised services.
SSOTrust External Identity Provider
Cross-domain identity.
FederationProtect Active Login State
After authentication.
Session ManagementStore Privileged Passwords
Central credential protection.
Credential VaultCreate Account on First Use
On demand.
Just-in-TimeApplication Authenticates
Not a person.
Service IdentityCertificate Identifies Laptop
Machine trust.
Device IdentityRisk Changes Authentication
Device / location / behaviour.
Adaptive Authentication⚠️ Common CISSP Mistakes IAM questions depend heavily on precise terminology
Claiming an identity is different from proving control of it.
Successful login does not grant unlimited access.
Both are knowledge factors.
Authentication still occurs using another mechanism.
MFA depends on the factors involved in the authentication event.
Authentication methods provide different levels of phishing resistance.
A compromised device can remain dangerous after legitimate authentication.
Recovery procedures must provide appropriate assurance too.
Proofing establishes who the identity belongs to.
Authentication later verifies control of that established identity.
A group collects identities.
A role represents responsibilities or permissions.
Reusing one credential independently across multiple systems is not SSO.
Each application still determines what the authenticated user may do.
Federation allows trusted identity assertions across security domains.
Sessions need protection, timeout and termination controls.
Both may need to be evaluated separately.
Services, applications and workloads require identity and authentication too.
Credential vaults improve management but become high-value security systems.
JIT is designed to provide access when required and reduce unnecessary long-lived access.
Quick Reference
| If you see... | Think... |
|---|---|
| Claim username | Identification |
| Verify claimant | Authentication |
| Determine allowed actions | Authorization |
| Record user activity | Accounting |
| Password / PIN | Knowledge Factor |
| Token / smart card / security key | Possession Factor |
| Fingerprint / face / iris | Inherence Factor |
| Different authentication factors | MFA |
| No traditional reusable password | Passwordless |
| Verify real-world identity before account creation | Identity Proofing |
| Bind authenticator to identity | Enrollment |
| Collection of identities | Group |
| Business function / responsibility | Role |
| One login across multiple apps | SSO |
| Trust another identity provider | Federation |
| Protect authenticated state | Session Management |
| Session expires after inactivity | Idle Timeout |
| Authenticate again before high-risk action | Reauthentication |
| Central protection for credentials | Credential Vault |
| Create access only when required | Just-in-Time |
| Laptop proves identity | Device Authentication |
| Application proves identity | Service Authentication |
| Location/device changes login requirement | Adaptive Authentication |
| Repeated MFA approval requests | MFA Fatigue |
| Stolen authenticated token | Session Hijacking |
AAA Memory Aid
Authentication Factor Memory Aid
MFA = different factors, not simply multiple passwords.
Identity Establishment Memory Aid
5.2 Master Memory Aid
The Identity Architect's Questions
Key Takeaways
Identification presents or claims an identity, while authentication verifies that the claimant legitimately controls that identity.
Authentication and authorization are separate decisions: proving who you are does not determine everything you may access.
AAA stands for Authentication, Authorization and Accounting.
Authentication establishes identity, authorization determines permitted actions and accounting records relevant activity.
Identity strategies must include people, devices and services rather than focusing only on human usernames.
User identity and device identity can be evaluated independently.
Applications, APIs, workloads and automated processes require their own identities and should follow least privilege.
Identity proofing establishes confidence that a digital identity belongs to the intended real-world entity before routine authentication begins.
Authentication cannot compensate for an incorrectly established identity.
The traditional authentication-factor categories are something you know, something you have and something you are.
MFA uses independent authentication factors. Two passwords are not MFA because both are knowledge factors.
Passwordless authentication removes the traditional reusable password from the authentication process but does not remove authentication.
Passwordless authentication is not automatically multi-factor; this depends on how the authenticator is designed and activated.
Context such as device, network, location, time and risk indicators can inform adaptive authentication decisions.
Strong authentication should be proportionate to the consequence of impersonation.
Authentication systems should consider threats such as phishing, credential stuffing, password spraying, brute force, MFA fatigue, credential theft and session hijacking.
Phishing-resistant authentication aims to reduce reliance on reusable secrets that users can accidentally disclose to attackers.
Groups allow identities to be administered together, while roles represent responsibilities and associated permissions.
Groups and roles improve scalability but require governance to prevent excessive membership and privilege accumulation.
SSO allows a user to authenticate once and access multiple authorised services without repeatedly performing separate primary authentication.
SSO does not mean using the same password independently on every system.
Centralised SSO improves consistency but creates an important concentration of security and availability risk.
Federated identity allows one domain to rely on identity information provided by another trusted identity provider.
Federation is therefore fundamentally a trust relationship.
After authentication, session management protects the authenticated state using controls such as timeout, logout, reauthentication and secure session identifiers.
Attackers may attempt to steal a valid authenticated session instead of defeating the original authentication mechanism.
Credentials require lifecycle management including issuance, protection, use, renewal, rotation, recovery and revocation.
Credential vaults can improve control over high-value secrets but become high-value security systems themselves.
Strong everyday authentication can be undermined by a weak account recovery process.
Just-in-Time approaches reduce standing access by creating or enabling identities and privileges when they are required.
A strong identity strategy considers how the identity is established, how it authenticates, what access it receives, how the resulting session is protected, how activity is recorded and how trust is eventually removed.
📚 Sources & Further Reading Identity proofing, authentication and digital-identity guidance
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-63-4 - Digital Identity Guidelines
View NIST Digital Identity Guidelines - NIST SP 800-63A-4 - Identity Proofing and Enrollment
View NIST identity-proofing guidance - NIST SP 800-63B-4 - Authentication and Authenticator Management
View NIST authentication guidance - NIST SP 800-207 - Zero Trust Architecture
View NIST Zero Trust Architecture