Layer by Layer
Confidence by Practice
Preparing your CISSP domains…
Read knowledge points freely. Practice, saved topics, progress and personal records require sign-in.
414 knowledge points
Access control identifies subjects, authenticates identities, authorizes permitted actions, and records activity so people, devices, and services can access only the assets needed for business tasks.
High-value assets often require both physical access controls and logical identity controls. Passing a physical checkpoint does not automatically grant system access, and logical authorization does not grant physical entry.
Distinctions: physical access vs logical access
A subject is an active entity requesting access, such as a user, process, device, service, or AI agent. Its identity must be verifiable and bound to authorization.
An object is a resource being accessed, such as a file, database, system, application, device, facility, or service. Access decisions should consider object sensitivity and business purpose.
Identification is a subject's claim of who it is, such as a username, device ID, or service principal. Identification alone does not prove identity.
Common traps: Entering a username is identification, not authentication.
Distinctions: identification vs authentication
Authentication verifies control of the claimed identity using evidence such as passwords, certificates, cryptographic keys, or multiple factors.
Distinctions: authentication vs authorization
Authorization determines which objects and operations an authenticated subject may access according to policy. Successful authentication does not grant all permissions.
Common traps: Authenticated does not mean authorized.
Distinctions: authorization vs authentication
Accounting and accountability record identities, access, changes, and high-risk actions so activity can be attributed, audited, and investigated. Shared accounts weaken accountability.
An access-control policy defines who may access which resources, under what conditions, and for what operations, providing governance for technical permissions.
Least privilege grants only the minimum permissions and scope needed for the current responsibility and removes them when no longer required.
Need to know limits information access to what a subject truly requires for the task even when the subject has sufficient clearance or role membership.
Distinctions: need-to-know vs clearance
Separation of duties divides high-risk authorization, execution, approval, and audit capabilities among different subjects to reduce fraud and abuse by one person.
Implicit deny means access that is not explicitly allowed is denied by default, a foundational secure-access principle.
Default-deny access control starts from restricted access and opens only explicitly authorized permissions rather than allowing broadly and blocking exceptions afterward.
Authorization can be enforced at system, application, file, record, field, API-operation, or facility-zone granularity. Finer granularity usually increases management complexity.
Information access control limits read, modify, copy, export, and sharing according to classification, owner decisions, need to know, and business purpose.
Read access primarily affects confidentiality and should follow need to know and classification. Read-only access can still be high risk because data can be disclosed.
Write access primarily affects integrity and should restrict who can create, modify, or delete critical data and record high-risk changes.
Delete access affects availability, integrity, and retention obligations and should be restricted and coordinated with backups, legal holds, and audit requirements.
The business Data Owner normally determines access needs and approves high-risk data access, while a custodian implements the corresponding technical controls.
System access control limits who can log in to hosts, servers, network devices, and platforms and which system-level operations they may perform.
Root, Administrator, and similar privileged accounts can alter security boundaries and should use least privilege, PAM, MFA, JIT elevation, and auditing.
Human users use interactive sessions, while service accounts and workloads often authenticate non-interactively. Their credential, timeout, and audit designs differ.
Device identity, ownership, posture, and network context can inform access decisions so every device capable of connecting does not receive equal permissions.
Managed devices can provide evidence of patch, encryption, EDR, and certificate state; unmanaged devices generally should receive more limited resource access.
Use certificates, hardware keys, TPM-backed identities, or managed identifiers to distinguish devices; IP or MAC address alone is not evidence that a device is trustworthy.
Facility access control uses badges, smart cards, biometrics, physical barriers, guards, and visitor controls to restrict entry to offices, server rooms, and high-security areas.
Badges map a person's identity to physical zones and support centralized revocation and logging, while borrowing, cloning, and tailgating require additional controls.
High-security entrances can use interlocked doors, identity verification, and sensors to reduce unauthorized tailgating while still meeting life-safety requirements.
Visitors should have identity verified, time and area restrictions, distinct credentials, and employee escorts according to risk.
Applications should enforce permissions at the business-operation layer and must not rely only on network location or a hidden user-interface function.
Roles should be permitted to invoke only approved business functions such as viewing, approving, paying, or administering. The server must enforce authorization rather than relying only on the UI.
Applications must verify a user's right to each specific record or object so changing an identifier cannot expose another user's data.
APIs, databases, queues, and backend services should use verifiable service identities and least privilege rather than trusting one another merely because they are on an internal network.
A service principal is a non-human identity representing an application or automation service and should have a defined owner, purpose, permissions, and lifecycle.
Workload identity gives containers, VMs, functions, or services short-lived verifiable identities and is preferable to long-lived shared secrets embedded in code.
Service-to-service calls require not only mutual authentication but also authorization for specific APIs, resources, and business actions so one credential cannot access every backend.
High-risk access should be approved by the business owner or delegated role that actually owns the risk. IAM administrators implement the decision rather than determining business need to know themselves.
In the 5.1 physical-access context, recertification periodically confirms that badge, zone, and facility permissions still match job, location, and employment status and connects to the formal Access Certification process in 5.5.
Distinctions: 5.1 physical-access scope vs 5.5 formal lifecycle certification process
In the 5.1 logical-access context, recertification periodically confirms that current user, device, and service permissions remain necessary, with special attention to privileged, third-party, and dormant accounts, and connects to the formal Access Certification process in 5.5.
Distinctions: 5.1 logical-access scope vs 5.5 formal lifecycle certification process
The component that actually permits or denies access must be placed where it cannot easily be bypassed, such as the application server, API gateway, database, or physical access-control point.
Centralized identity and policy improve governance consistency and auditing, but an IdP, directory, or PDP becomes a high-value dependency requiring protection and resilience.
Decentralized systems with independent accounts and permissions reduce dependence on one platform but commonly create permission drift, orphaned accounts, and audit difficulty.
When an identity service, directory, or policy engine fails, fail-open or fail-closed behavior should be predetermined; high-security, life-safety, and availability needs can lead to different choices.
Prepare controlled emergency-access accounts or procedures for major incidents or IAM failure. Protect them strongly, alert on use, audit activity, and review afterward.
Shared accounts weaken authentication and accountability. Prefer individual identities and share privileges through roles or PAM rather than shared passwords.
Generic accounts may lack a clear owner and individual attribution. If required by the business, constrain their purpose and strengthen credential management and monitoring.
An orphaned account remains after its owner leaves or business purpose ends, creating an unmanaged access path. Lifecycle processes and reviews should promptly disable or remove it.
A dormant account has been unused for an extended period and can be forgotten and attacked. Detect it automatically and disable it or require renewed approval.
Log successful and failed authentication, authorization denials, permission changes, and access to high-risk resources to support anomaly detection and audit.
Access control determines who may use data, while encryption and related data-protection controls determine under what state or conditions data can be read. They are complementary, not substitutes.
Manage an AI agent as a distinct non-human identity rather than reusing a developer or shared administrator credential; its owner, purpose, and permissions must be traceable.
AI agents must follow least privilege and receive only the data, APIs, and tools needed for the assigned task, with high-risk write, delete, or administrative operations constrained to reduce impact if the agent is manipulated.
A model's output must not define its own authorization scope. External IAM policy and explicit approval should constrain privileged tool calls so prompt injection cannot become privilege escalation.
An identification and authentication strategy defines how people, devices, and services are registered, proofed, issued credentials, authenticated, given sessions, recovered, and retired, with assurance strength selected according to risk.
Human identities are typically anchored to HR, contract, customer, or similar authoritative records, with lifecycle changes driven by onboarding, job change, and termination.
Device identity should use manageable certificates, keys, or hardware roots of trust and be associated with device ownership, posture, and lifecycle.
Services and automation require separate non-human identities, clear ownership, short-lived credentials, and least privilege rather than shared long-lived secrets.
Each accountable subject should have a unique identity so multiple people do not share one identifier and undermine auditability and revocation.
Design identifiers that are unique, stable, and mappable across systems. Changes to display names or email addresses should not break underlying identity continuity.
Groups and roles make permission management easier than per-user grants, but nesting, inheritance, and role growth can create excessive access.
A security group collects multiple subjects under common authorization policy; membership itself should have an owner, approval process, and periodic review.
A distribution group primarily supports message distribution, while a security group supports authorization. Similar names do not make them interchangeable.
A role should represent a stable business responsibility and permission set rather than a one-off copy of an individual's current access.
Role engineering analyzes business processes, job responsibilities, and existing permissions to build maintainable roles and reduce fragmented permissions and role explosion.
Creating a new role for every exception or minor difference leads to role explosion; attributes, conditions, and formal exception handling can supplement roles.
Nested groups simplify administration but can hide actual effective permissions and make access reviews harder.
Effective permissions result from direct grants, groups, roles, inheritance, conditions, and allow or deny rules; reviews must examine the resulting effective access.
AAA means Authentication verifies identity, Authorization determines permitted actions, and Accounting records activity, together supporting access control and accountability.
Classic authentication-factor categories include something you know, have, and are, with some designs also considering somewhere you are and something you do. True MFA uses different factor categories.
Passwords and PINs are knowledge factors and are vulnerable to phishing, guessing, and reuse; mitigate with appropriate password controls, risk management, and additional factors.
Smart cards, hardware tokens, phones, and security keys are possession factors. Theft of the device still requires activation controls or effective revocation.
Fingerprints, facial features, and irises are biometric identity characteristics. Unlike passwords, biometric data cannot be easily changed after compromise.
Keystroke rhythm, signature motion, gait, and other behavioral characteristics can support continuous or risk-based authentication but are sensitive to environmental variation and model error.
Geographic or network location can be a contextual or risk signal but can be spoofed and normally should not serve as the sole factor for high-assurance authentication.
MFA requires two or more proofs from different factor categories and significantly reduces risk from compromise of one password.
Two-factor authentication is a form of MFA using exactly two different factor categories. Two passwords are not 2FA.
Entering two credentials from the same category in sequence is multi-step authentication, not true MFA; the factor categories must differ.
MFA fatigue or push bombing repeatedly sends approval prompts hoping the user accepts one. Number matching, phishing-resistant MFA, rate limiting, and anomaly detection reduce risk.
Phishing-resistant authentication binds the credential to the legitimate verifier or origin so a fake login page cannot simply relay it, as with WebAuthn or FIDO2-style public-key authentication.
Passwordless authentication avoids a memorized password and can use public-key security keys, passkeys, or hardware-protected multifactor methods. Passwordless does not automatically mean multifactor or risk-free.
Passwordless describes whether a password is used; MFA describes the number and categories of factors. A passwordless method may be single-factor or multifactor.
An authenticator is a secret, device, or mechanism used to prove control of an identity, such as a password, security key, OTP token, or certificate private key.
Authenticator binding securely associates a particular authenticator with a subscriber or account; enrollment, replacement, and recovery are as security-sensitive as normal login.
Before registering an initial or additional authenticator, confirm the subject's identity so an attacker cannot enroll their own MFA device on the account.
Authenticator recovery after loss must provide assurance comparable to normal authentication or attackers will bypass strong MFA through a weak help-desk process.
Password reset, MFA reset, and device replacement are high-risk recovery paths and should use identity verification, alerting, cooling-off periods, or human approval according to risk.
Knowledge-based authentication based on birthdays, addresses, or security questions is often obtainable from public data or breaches and is unsuitable as the core of high-assurance identity verification.
Modern password policy should emphasize length, blocking compromised passwords, rate limiting, and secure storage rather than relying primarily on frequent forced changes and rigid composition rules.
Adequate password length usually contributes more to guessing resistance than forced character-composition rules, and systems should permit long passwords generated by password managers.
Rules requiring upper or lowercase, numbers, and symbols can drive predictable patterns and reuse and do not replace length, breached-password screening, and MFA.
Without evidence of compromise, frequent forced password changes can encourage predictable variants; change passwords on compromise, reset, or risk events.
Password reuse spreads a credential breach from one service to others. Block known-compromised passwords and promote password managers and MFA.
Credential stuffing uses usernames and passwords leaked from other services in bulk login attempts and primarily exploits password reuse; MFA and compromised-password detection reduce risk.
Password spraying tries a few common passwords against many accounts to avoid per-account lockout thresholds; detect abnormal patterns, use intelligent lockout, and eliminate weak passwords.
Brute-force login attacks try many passwords against one or a few accounts. Use rate limiting, delays, MFA, and anomaly detection rather than relying only on permanent lockout.
Account lockout after repeated failures can slow guessing, but overly strict lockout can be abused for denial of service.
Authentication throttling or rate limiting progressively delays or restricts attempts, reducing automated guessing while avoiding some DoS risk from rigid lockout thresholds.
A password manager generates and stores unique strong passwords, reducing reuse. Its master credential, endpoint security, and synchronization model are the main trust risks.
A credential vault centrally protects high-value passwords, API keys, and privileged credentials and can support access control, rotation, checkout, and auditing.
In the 5.2 credential-management context, a privileged credential vault centrally protects high-value administrative credentials and supports access control, automatic rotation, and controlled retrieval; it is the storage and lifecycle mechanism used by PAM checkout processes in 5.5.
Common traps: Do not treat a vault as an ordinary shared password file. A vault does not eliminate the need for approval, controlled checkout, or session auditing.
Distinctions: 5.2 credential-storage/lifecycle mechanism vs 5.5 privileged-use workflow vault protects and rotates credentials; checkout governs temporary use
A secrets manager securely stores and dynamically delivers API keys, passwords, and tokens to applications and workloads instead of embedding them in code or configuration.
Credential rotation replaces passwords, keys, and tokens based on risk, compromise events, or lifecycle. Short-lived dynamic credentials reduce exposure from long-lived secrets.
Credential revocation makes a compromised or no-longer-valid credential unusable and ensures dependent systems promptly honor the revoked state.
Single Sign-On lets a user perform one primary authentication and then access multiple trusted applications, improving usability and centralized control while increasing the impact of IdP compromise.
SSO reduces password count and centralizes authentication policy and revocation, improving user experience and governance.
Compromise of a central IdP or SSO session can affect many applications, so SSO needs strong MFA, session protection, resilience, and risk monitoring.
SSO is an authentication or user-experience objective, while federation is a mechanism for conveying identities and claims across security domains. They are often combined but are not synonyms.
After authentication, sessions or tokens maintain identity state and require secure creation, binding, timeout, renewal, revocation, and termination.
Session identifiers must have high entropy, be unpredictable, and be transmitted over protected channels so they cannot be guessed or stolen easily.
Session fixation causes a victim to authenticate using a session identifier known to the attacker; regenerate the session identifier after authentication.
Session hijacking uses a stolen session cookie or token to impersonate an authenticated user; protect tokens, use TLS, limit lifetime, and bind sessions to appropriate context.
Idle timeout requires reauthentication after a period without user activity, reducing risk from unattended terminals and stolen sessions.
Absolute timeout forces reauthentication after a maximum total session duration regardless of continued activity, limiting abuse of long-lived tokens.
Reauthentication verifies the subject again for high-risk actions, long-lived sessions, or changed risk conditions, reducing exposure from session hijacking and context changes.
Step-up authentication requires stronger factors or a higher assurance level for sensitive resources or high-risk actions rather than imposing maximum friction on every action.
Continuous authentication evaluates device, behavior, and environmental signals during a session and can trigger reauthentication or restrictions when risk changes.
Identity registration creates a digital identity record and associates the subject with a unique identifier, forming the starting point for credential and authorization lifecycle management.
Identity proofing collects, validates, and binds evidence to an applicant to increase confidence in a real-world identity claim; strength should match the impact of proofing failure.
Government IDs, trusted digital credentials, and other evidence can support identity claims. Authenticity of the evidence and binding it to the applicant are distinct checks.
Identity verification confirms that the applicant is the person represented by the presented identity evidence, such as through in-person comparison, remote live capture, or another verification process.
Identity validation confirms that identity attributes and evidence are valid and consistent with authoritative or trusted sources, distinct from proving that the applicant owns that identity.
After successful proofing, establish a trusted digital identity, assign an identifier, and bind authenticators so later authentication can trace back to the entity.
NIST Identity Assurance Level measures confidence in identity proofing and real-world identity binding and is separate from Authentication Assurance Level and Federation Assurance Level.
Under NIST SP 800-63-4, IAL1 provides baseline identity-proofing assurance by validating core attributes and associating evidence with the applicant.
IAL2 requires additional or stronger evidence and more rigorous validation for cases with higher impersonation impact.
IAL3 requires attended, in-person proofing with direct interaction by a trained representative and collection of at least one biometric sample.
Authentication Assurance Level measures the strength of the authentication process and authenticator binding, with AAL1, AAL2, and AAL3 representing increasing assurance.
AAL1 provides basic authentication assurance and may use single-factor or multifactor authentication.
AAL2 requires two distinct authentication factors using approved cryptography; current NIST guidance also requires offering a phishing-resistant option.
AAL3 provides very high assurance using a non-exportable public-key cryptographic authenticator with phishing resistance and verifier-compromise protection.
IAL answers how reliably the digital identity is bound to a real person; AAL answers how strongly the current login proves control of authenticators. They are different dimensions.
Federated Identity Management establishes trust across security domains so an IdP in one domain can provide verified identity and attribute assertions to a relying party in another.
An Identity Provider authenticates subjects and issues identity assertions or tokens to relying parties, making it a high-value trust center in federation.
A Relying Party or Service Provider trusts identity assertions from an IdP to create local sessions and authorization context, but must still validate the token and enforce its own authorization policy.
Federation must explicitly define trusted issuers, audiences, keys, claims, and revocation behavior. Misconfigured trust relationships can enable cross-domain privilege abuse.
Federation assurance includes not only user-authentication strength but also protection against assertion forgery, injection, IdP compromise, and claim-integrity failure.
Federation Assurance Level measures protection of the federated transaction that carries identity and attribute information from IdP to RP and is separate from IAL and AAL.
NIST SP 800-63-4 increases FAL protection according to federation failure impact, from protected assertions to injection resistance and stronger protection against IdP compromise.
Credential-management systems centrally manage creation, storage, distribution, rotation, revocation, and auditing of passwords, keys, certificates, tokens, and similar credentials.
Maintain an inventory showing who owns critical credentials, what systems they serve, where they are stored, and when they expire to avoid unknown secrets and certificate outages.
Issue credentials only after identity and authorization are established and deliver them to the correct subject over a protected channel.
Credential binding explicitly associates a credential with a particular identity, device, or service principal to prevent accidental sharing or transfer.
On credential compromise, revoke and rotate the credential, terminate affected sessions, assess access scope, and investigate misuse.
Just-In-Time access grants privilege only when needed and automatically removes it when the task or time window ends, reducing standing privilege.
Standing access remains continuously available; JIT access activates only for a short need. JIT reduces exposure time but still requires approval, identity, and audit.
Just-Enough-Administration limits administrators to only the commands or functions needed for a specific task and can combine with JIT to reduce both privilege scope and duration.
Time-bound access has an explicit expiration and is useful for temporary projects, third parties, and privileged tasks so access is not forgotten.
Adaptive authentication dynamically changes authentication requirements or blocks access based on user, device, location, time, behavior, and threat signals.
Risk-based authentication reduces friction for low-risk logins and requires step-up or denial for high-risk events; risk signals do not replace authorization policy.
Behavioral biometrics use keystroke, mouse, touch, and login patterns to support continuous or adaptive authentication, with attention to false positives, bias, and privacy.
AI can analyze login, device, and behavioral anomalies to trigger step-up authentication or blocking, but model output should be a risk signal rather than an opaque sole access decision.
AI agents and automation services should use separate, rotatable, short-lived, revocable credentials rather than shared human accounts or long-lived static API keys.
Third-party federation uses a controlled trust relationship with an external or shared IdP to provide identities to local applications and must define issuer, audience, claims, keys, sessions, and termination boundaries.
Using third-party identity makes part of the authentication assurance depend on an external IdP; the relying party still owns authorization, sessions, and protection of its resources.
Compromise of an IdP can affect many relying applications and tenants, so protect administrators, signing keys, MFA, logs, and recovery processes.
A relying party must validate token/assertion signature, issuer, audience, time constraints, and required claims rather than accepting an assertion merely because it came from a familiar domain.
A federated claim is an IdP statement about subject identity or attributes such as subject, group, email, or authentication context. An RP should trust only explicitly approved claims.
Federation should transmit only the attributes the RP actually needs, reducing privacy exposure and overauthorization.
Mapping external IdP attributes into local accounts, groups, or roles must prevent naming conflicts and unintended privilege escalation.
Federation should prefer a stable unique subject identifier rather than a changeable or reusable email address as the sole account key.
Automatically creating a local account on first federated login reduces preprovisioning effort but requires restrictive default permissions and reliable termination/revocation handling.
When an external identity is disabled, a partnership ends, or a user leaves, local accounts and sessions must also be terminated promptly rather than waiting for the next login.
On-premises federation lets an organization operate its own directory/IdP and retain more infrastructure control while assuming responsibility for availability, keys, and patching.
An on-premises IdP can become the login dependency for many applications and therefore requires redundancy, backups, accurate time, and disaster recovery.
Federation signing keys determine assertion trust and should use strong access controls, protected keystores or HSMs, rotation, and recovery procedures.
Cloud federation uses a cloud IdP or SaaS identity platform for authentication and federation, providing scalability while requiring clear responsibility boundaries, tenant configuration, and supplier dependencies.
The cloud provider protects identity-platform infrastructure, while the customer still owns administrator accounts, MFA, domain configuration, application trust, claims, and user lifecycle.
Multi-tenant identity platforms must isolate customer directories, keys, and configuration, and customers must avoid accidental cross-tenant trust relationships.
Hybrid federation combines on-premises directories with cloud IdPs and often uses account/password-hash synchronization, agents, or federation servers, adding consistency and failure boundaries.
Directory synchronization must define the source of authority, attribute direction, conflict handling, and deletion propagation so stale accounts do not survive on one side.
Specify whether HR, a customer system, on-premises directory, or cloud directory is authoritative for each identity attribute to avoid conflicting bidirectional changes.
Synchronizing unnecessary attributes, password hashes, or privileged groups expands the impact of cloud or on-premises compromise; minimize scope and protect synchronization agents.
An on-premises federation server may issue assertions trusted by many cloud services and is therefore a high-value target, especially if its signing key is compromised.
SAML is an XML-based federation protocol in which an IdP sends authentication and attribute assertions to an SP and is widely used for enterprise web SSO.
A SAML assertion can carry authentication, attribute, or authorization decision statements about a subject; the exact contents depend on the applicable profile and use case. Integrity protection may be applied at the assertion or SAML Response level as required by the profile or deployment. The SP must validate the applicable IdP signature or other required protection, issuer and trust relationship, audience, recipient, conditions, and time bounds.
In IdP-initiated SSO, the user starts at the IdP and receives an assertion for the SP. It is convenient but provides less SP-request context, requiring careful replay and recipient controls.
In SP-initiated SSO, the user first visits the SP, which creates an authentication request and redirects to the IdP; the returned SAML Response/assertion is correlated with the original request where the profile requires it, and the SP validates the applicable signature or other required protection, issuer, audience, recipient, conditions, and time bounds.
The SP must validate the intended signed XML element and trusted certificate so XML signature wrapping or parsing inconsistencies cannot cause acceptance of attacker-controlled assertions.
Limit SAML assertion validity, recipient, and audience and track one-time identifiers as appropriate to prevent replay of captured assertions.
OAuth 2.0 is primarily a delegated authorization framework that lets a client access a resource server without receiving the user's password; OAuth itself is not an authentication protocol.
OAuth 2.0 is an authorization framework, not an authentication protocol. An Access Token represents delegated resource access and is not by itself proof of the end user's authenticated identity; use OpenID Connect when an identity layer is needed.
Common traps: Do not assume that possession of an OAuth token proves the user has been authenticated. Do not use an Access Token as though it were an OIDC ID Token.
Distinctions: OAuth vs OIDC
The OAuth resource owner is the entity able to authorize client access to a protected resource, commonly the end user.
The OAuth client is an application requesting access to a resource server on its own behalf or on behalf of a resource owner.
The OAuth authorization server evaluates authorization conditions and issues access tokens to clients, making it a central trust component.
The OAuth resource server hosts protected APIs and decides access after validating access-token properties such as scope, issuer, audience, and lifetime.
An OAuth access token is the credential a client presents to a resource server for authorized access and should have minimum scope, short lifetime, and strong protection from disclosure.
A refresh token obtains new access tokens without repeating the full user-authorization flow. It is often longer-lived and higher value and therefore needs strict protection, rotation, and revocation.
OAuth scope limits the API privileges conveyed by a token but is not a complete business-authorization model; the resource server still needs object-level and action-level authorization.
The authorization-code flow sends only a short-lived code through the front-channel browser and exchanges it for tokens at the client; modern public clients should use PKCE.
PKCE binds an authorization code to a one-time client secret/value so interception of the code does not allow another client to redeem it easily.
Modern OAuth security practice discourages the implicit grant and similar flows that expose access tokens directly through the front-channel URL; use authorization code plus PKCE instead.
The Resource Owner Password Credentials grant requires the client to collect the user's password and breaks the delegated-authorization boundary; modern OAuth security practice should not use it.
OpenID Connect adds an identity layer to OAuth 2.0 and uses an ID Token to convey authentication results and user identity, commonly for modern web and mobile SSO.
An OIDC ID Token is commonly a signed JWT intended for the client/RP and conveys user authentication and claims. It is not the API access token.
An ID Token lets the client confirm authenticated identity; an Access Token authorizes calls to a resource server. Their audiences and purposes differ.
JWT is a compact token format that can be signed or encrypted. It is only a container; the contents are not automatically trustworthy and require validation of algorithm, signature, issuer, audience, and time claims.
A JWT receiver must verify an expected algorithm and trusted-key signature and validate claims such as issuer (iss), audience (aud), expiration (exp), and not-before (nbf). Base64-decoding the token does not establish trust.
Federation metadata distributes IdP/SP endpoints, certificates, and capabilities. Automated refresh is convenient, but the source and changes must be authenticated and reviewed.
When an IdP rotates signing keys, RPs must securely obtain the new key and support overlap during transition so rotation does not cause outages or acceptance of malicious keys.
Logging out of one RP, the IdP session, and all federated applications are different actions. Single Logout is complex, and local logout should not be assumed to terminate every federated session.
Contracts for third-party federation should define identity assurance, MFA, logging, incident notification, availability, data handling, administrator responsibility, and termination/migration requirements.
AI agents and service identities federated across clouds or third-party AI platforms should use explicit issuers, audiences, and minimum scopes rather than forwarding a human user's long-lived privileged credentials.
Select authorization models according to business roles, data classification, environmental attributes, risk, and management complexity. Real systems often combine several mechanisms.
When an authenticated subject requests an object, evaluate policy, subject, object, action, and context to produce Permit, Deny, or another defined decision.
An entitlement is a specific resource, role, group membership, or operational privilege granted to a subject and should have an owner, justification, and lifecycle.
A permission is the right to perform a particular action on an object, such as read, write, approve, or execute. Multiple permissions can be grouped into a role.
An access-control matrix expresses permissions across subjects and objects and is the conceptual basis for implementations such as ACLs and capabilities.
An Access Control List is object-centered and lists which subjects or groups have which permissions to an object.
Distinctions: ACL vs capability
Capability-based authorization gives a subject an unforgeable capability or token proving specific rights to an object, naturally expressing what the subject can access.
Distinctions: capability vs ACL
RBAC assigns permissions to roles and users to roles, fitting organizations with relatively stable responsibilities and reducing per-user grants.
Users are assigned to roles according to job and business responsibility, and role membership should change promptly when responsibilities change.
Grant permissions to business roles rather than copying them directly to individuals, improving approval, review, and revocation.
Role hierarchies let senior roles inherit permissions from base roles, reducing duplication while potentially obscuring effective access and increasing privilege.
RBAC constraints such as mutually exclusive roles, cardinality limits, and prerequisite roles can implement separation of duties and other risk controls.
Static separation of duties prevents one user from simultaneously receiving conflicting roles, such as payment creation and payment approval.
Dynamic separation of duties may let a user possess several roles but prevents conflicting roles from being active within the same session, transaction, or business instance.
Role mining analyzes current permissions and business patterns to find candidate roles, but historical access may already contain excessive privilege and should not be treated as a correct target design.
Creating roles for every contextual exception makes RBAC difficult to manage. ABAC or conditional policy may be a better way to express highly variable conditions.
RBAC is easy to understand and audit when permissions are driven mainly by stable jobs or responsibilities; highly dynamic environments can create excessive numbers of roles.
Rule-based access control evaluates system-defined rules such as network, time, protocol, or operational conditions; ordinary users normally cannot change the rules themselves.
RBAC bases decisions mainly on business-role membership; rule-based control bases decisions on system conditions and rules. They can be combined.
A firewall allowing traffic by source, destination, and protocol is an intuitive rule-based-control example, while IAM authorization can incorporate richer identity attributes.
Mandatory Access Control uses security labels and centrally enforced policy. Ordinary users cannot freely change object labels or authorization rules and it is common in multilevel-security contexts.
MAC decisions use subject clearance and object classification/category labels maintained through trusted administrative processes.
Clearance is the maximum security level approved for a subject; it does not automatically establish need to know for every item at that or a lower level.
Compartments or categories such as project, topic, or organization can further restrict access beyond level; the subject must satisfy required categories.
MAC is centrally enforced through labels and policy, while DAC permits an owner to make access decisions within policy. MAC generally provides less user discretion.
Discretionary Access Control lets a resource owner or authorized subject decide who may access an object, often through ACLs; it is flexible but depends heavily on correct owner decisions.
In DAC, an object owner can normally grant or revoke permissions, so compromise or mistakes by the owner can propagate inappropriate access.
If recipients can further delegate permissions, access can spread over time. Limit grant rights and audit delegation.
ABAC dynamically evaluates policies using subject, object, action, and environmental attributes and suits fine-grained, cross-organizational, and cloud authorization.
Subject attributes can include department, job, clearance, employment status, and device trust and must come from trustworthy authoritative sources.
Object attributes can include classification, owner, project, and data type; incorrect labels directly produce incorrect authorization.
Environmental attributes such as time, location, network, risk score, and device posture can dynamically influence authorization.
Different actions such as read, write, delete, approve, and export can have different ABAC policy conditions.
An ABAC rule might allow Finance staff to read specified financial data only from managed devices during work hours when risk is low, demonstrating multi-attribute rather than single-role decisions.
ABAC expresses complex dynamic conditions and can reduce role explosion, but depends on high-quality attributes, sound policy governance, and explainability.
Large numbers of attributes and policies can make effective access difficult to predict; test conflicts, default behavior, and attribute sources.
RBAC uses stable roles as the primary decision input, while ABAC dynamically evaluates multiple attributes and context. A common design uses RBAC for baseline access and ABAC for additional conditions.
Risk-based access control dynamically permits, denies, or requires step-up based on current transaction or login risk such as location, device, behavior, or resource sensitivity.
A risk score should be one explainable policy input rather than letting a black-box model alone make every high-impact authorization decision.
Context-aware access dynamically adjusts authorization using user, device, time, location, network, application, and threat information and is an important implementation pattern for Zero Trust and adaptive access.
Conditional access permits access only when specified conditions such as MFA, managed device, approved location, or an acceptable risk threshold are satisfied.
Continuous authorization keeps evaluating risk and attribute changes after a session begins and can reduce privileges or terminate the session instead of treating authorization as permanent.
A Policy Decision Point evaluates policy and request context to calculate an authorization decision and requires trustworthy attributes, high availability, and integrity.
A Policy Enforcement Point intercepts requests at the resource boundary and enforces the PDP decision. It must be difficult to bypass, such as an API gateway, application middleware, or network proxy.
A Policy Information Point provides subject, device, resource, and environmental attributes to a PDP. Incorrect PIP data can produce incorrect authorization.
A Policy Administration Point creates, maintains, and publishes authorization policy and requires change control, separation of duties, and audit.
The PDP decides whether access should be allowed; the PEP intercepts the request and enforces that decision. Decision and enforcement are distinct functions.
For high-security resources, a PEP should normally default to deny when it cannot obtain an explicit Permit or the policy service fails, unless business or life-safety needs explicitly require another failure mode.
Roles, groups, deny/allow rules, attributes, and resource policies can conflict, so define explicit precedence and policy-combining behavior.
Many platforms give explicit deny precedence over allow, but exact rules differ. CISSP focuses on ensuring conflict resolution is explicitly defined rather than assumed.
Permission inheritance from parent directories, groups, or roles simplifies management but nested inheritance and exceptions can create unexpected effective access.
Permission creep occurs when users retain old access after job and project changes until permissions exceed current responsibilities; periodic review and role-transition processes reduce it.
Caching authorization decisions improves performance but can delay revocation or risk changes; use short TTLs or active invalidation for sensitive access.
Fine-grained authorization controls specific API actions, data objects, or fields and reduces overprivilege while requiring more mature policy, attributes, and testing.
Coarse-grained authorization at application, network, or broad-role level is simpler to manage but can expose more resources than the task requires.
APIs must validate token privileges and scope and also enforce object-level access; authentication at login or a client-provided role is insufficient.
OAuth scope limits categories of API operations represented by a token, but the resource server must still verify whether the user or service is authorized for the specific business object and action.
Database authorization can use roles and schema/table/row/column permissions; an application account should not automatically have DBA privileges.
Privileged authorization should be explicitly approved, minimized, time-limited, and audited so ordinary accounts do not retain administrator roles indefinitely.
Break-glass authorization may bypass portions of the normal process only under predefined policy and must generate immediate alerts and post-use review.
Authorization design should let a business owner understand who has which permission and why; excessively complex policies undermine governance.
AI can generate risk scores from login and behavior anomalies for conditional access or a PDP, but high-impact authorization should retain explainable policy, human governance, and fallback behavior.
When an AI agent invokes databases, email, repositories, or execution tools, an external PEP should authorize each call; the model should not decide to exceed its predefined privileges.
Identity lifecycle management governs an identity from creation and enablement through changes, suspension, and termination, driven by authoritative business events and synchronized across accounts, roles, credentials, and sessions.
The Joiner-Mover-Leaver lifecycle uses onboarding, job changes, and departures as authoritative triggers for creating, changing, and removing access.
An account access review periodically asks an appropriate business or resource owner to confirm that current access for user, system, and service accounts remains necessary.
A user access review evaluates roles, groups, direct grants, and privileged access against current job duties to identify permission creep and obsolete access.
A system-account review confirms the account still has an owner and valid business purpose, uses least privilege, and has current credentials rather than preserving unexplained legacy administrative or technical accounts.
A service-account review confirms that the associated application or task still exists, the account has an accountable owner, permissions remain minimal, interactive login is controlled, and credentials are rotated appropriately.
In the 5.5 governance context, Access Certification is the formal activity in which an appropriate business or resource owner certifies entitlements and records auditable keep/remove decisions. It can cover both physical and logical access and connects to the recertification concepts in 5.1.
Distinctions: 5.5 formal governance/process view vs 5.1 physical/logical access-scope views certification decision vs technical permission implementation
Access-review frequency should reflect user type, resource sensitivity, regulatory requirements, and risk; privileged, third-party, and high-impact access commonly require more frequent review.
A reviewer should understand the business need for the access and should not simply approve their own permissions. High-risk access may require independent or multiple reviewers.
Access-review evidence should record scope, reviewer, decisions, exceptions, and remediation so the organization can demonstrate that certification actually occurred.
Access-review remediation must actually remove or correct unnecessary access and verify completion; a review that only produces a report does not reduce risk.
Provisioning creates accounts, assigns approved permissions, binds credentials, and establishes ownership based on an authorized identity, role, and resource need.
Automated provisioning uses authoritative HR or IGA events to create and update access consistently and quickly, but incorrect source data or rules can propagate mistakes across many systems.
Manual provisioning through ad hoc tickets can be delayed, missed, or based on copied permissions. Standard roles, clear approvals, automation, and verification reduce these risks.
Birthright access is a small baseline set of permissions automatically granted to users who meet defined business criteria and should be removed automatically when those criteria no longer apply.
Request-based access covers permissions beyond birthright access and requires an explicit request, appropriate owner approval, and policy checks before provisioning.
Approval workflows route access requests to the manager, application owner, data owner, or risk owner responsible for the decision; IAM operators should not independently determine business need.
Provisioning separation of duties divides requesting, approving, and executing access changes so one person cannot authorize and implement their own high-risk access.
Deprovisioning disables or deletes accounts, revokes tokens and certificates, terminates sessions, and removes groups, roles, remote access, and other permissions when access is no longer justified.
For involuntary or otherwise high-risk termination, access should be disabled immediately at the authorized termination point to reduce sabotage, theft, or retaliation risk.
A planned departure may permit controlled handoff and continuity activities, but access should not be extended indefinitely beyond business need or the departure date.
Disabling an account may not terminate existing sessions or refresh tokens. Deprovisioning should actively invalidate sessions and tokens that could otherwise remain usable.
Deprovisioning should revoke passwords, certificates, API keys, security keys, VPN tokens, and other authenticators associated with the departing identity.
Physical-access deprovisioning should remove badges, keys, parking, and facility permissions in coordination with logical-access termination.
When a contract, project, or partnership ends, revoke third-party accounts, VPN access, federation relationships, and shared-resource permissions rather than assuming an external organization will handle every local entitlement.
Orphan-account cleanup reconciles HR, CMDB, and ownership records to identify and disable accounts with no valid owner, employment relationship, or business purpose.
A mover or transfer process should add the access required for the new role and remove access from the old role rather than only accumulating new permissions.
A short add-before-remove overlap may support business continuity, but high-risk separation-of-duties roles should avoid conflicting simultaneous access and use a controlled transition.
A role transition should trigger reassessment of all effective permissions, separation-of-duties conflicts, and old-role access rather than merely assigning the new role.
Role-definition governance assigns an owner, business purpose, permission set, separation-of-duties constraints, and review cycle to a role instead of turning one person's historical access into a permanent role.
A role owner is accountable for the role's business meaning, membership rules, and appropriateness of permissions; IAM administrators implement the approved design.
Roles have their own lifecycle and should be created, changed, reviewed, and retired so unused legacy roles do not preserve hidden privileged access.
Privilege escalation means obtaining higher or different privilege and can be a legitimate administrative action or an attack; the key distinction is whether the elevation was authorized, constrained, and auditable.
Vertical privilege escalation lets a lower-privileged subject obtain administrator or otherwise higher-level privilege.
Horizontal privilege escalation lets a subject access another user's or peer object's resources at the same nominal privilege level; the authorization boundary is broken even without becoming an administrator.
Authorized privilege elevation grants temporary higher privilege for an approved task and should be time-limited, audited, and automatically reverted when the task ends.
On Unix/Linux systems, sudo can allow an authorized user to run specified commands as another identity according to policy, reducing the need for direct root login.
Sudo policies should restrict commands, target identities, and conditions. Broad ALL permissions can turn a normal administrator into a permanently privileged root-equivalent account.
Sudo auditing should record who invoked which command, when it occurred, and under which target identity to preserve accountability for elevated actions.
su typically switches to another complete identity and may use the target account's password, while sudo executes selected privileged commands under policy and generally provides stronger individual attribution.
Privileged Access Management (PAM) controls privileged credentials and sessions through capabilities such as vaulting, approval, JIT elevation, credential rotation, session proxying, and audit.
Privileged session management proxies, monitors, or records high-risk administrative sessions and can enforce command restrictions or terminate activity in real time.
In the 5.5 lifecycle context, privileged credential checkout is the approved temporary retrieval of a privileged credential from a vault, followed by return, invalidation, or rotation after the task. Checkout is the access process; the vault in 5.2 is the credential-storage and lifecycle mechanism.
Common traps: Credential checkout is not a long-term assignment of an administrator password. Do not omit return, revocation, or rotation after the privileged task.
Distinctions: 5.5 privileged-use workflow vs 5.2 credential-storage/lifecycle mechanism checkout = temporary controlled use; vault = protected storage/rotation
Reducing standing privilege through JIT, JEA, and temporary role activation limits both the duration and scope of administrative rights available to an attacker.
An emergency or break-glass privileged account should be strongly protected, monitored, tested periodically, and generate immediate alerts when used.
A service account should have a unique purpose, accountable owner, least privilege, restricted interactive login, protected credentials, rotation, and a defined retirement process.
Every service account should have an accountable application or business owner who can approve permissions, credential rotation, and retirement decisions.
Backend service accounts generally should not permit ordinary human interactive login because doing so increases lateral-movement opportunities and weakens attribution.
Static service-account passwords should be rotated safely and synchronized with all dependencies; leaving them unchanged for years creates persistent credential risk.
A managed service account lets the platform manage password or key lifecycle and rotation, reducing manual credential handling and synchronization errors.
Machine identities for devices, workloads, certificates, and service principals require creation, ownership, renewal or update, revocation, and retirement just as human identities do.
API keys should be uniquely attributable, minimally scoped, rotatable, revocable, and kept out of source code. Shared long-lived keys weaken both security and accountability.
Identity certificates require issuance, binding, renewal, revocation, and expiration management; expired or stolen certificates can cause either outages or impersonation.
Temporary, project, contractor, and third-party access should carry an explicit expiration so it is removed automatically rather than relying on someone to remember later.
Long-unused high-risk entitlements can be a useful signal during review, but lack of use alone is not sufficient evidence for deletion without validating legitimate business need.
A toxic combination occurs when individually reasonable permissions together bypass separation of duties or enable fraud; role design and access reviews should evaluate combinations, not just individual grants.
Identity Governance and Administration (IGA) combines lifecycle management, access requests, role governance, certification, and separation-of-duties controls.
Identity reconciliation compares authoritative identity records with actual target-system accounts and entitlements to find missing synchronization, manual accounts, orphaned identities, and drift.
A provisioning connector often has broad rights to create, change, and delete many accounts. Protect its secrets, minimize scope, and monitor anomalous activity because connector compromise can propagate widely.
After termination or other deprovisioning, verify that critical applications, cloud services, VPNs, facilities, and third-party systems actually removed access rather than treating ticket closure as proof.
Lifecycle SLAs define expected timing for onboarding, emergency termination, transfers, and access removal so IAM operational performance can be measured against business risk.
An AI agent should be governed like another non-human identity, with an accountable owner, creation basis, access reviews, credential rotation, and retirement when the model or business use ends.
An AI agent should not be able to expand its own access because of a model output or task chain; higher privilege should be constrained through external policy, JIT elevation, PEP/PDP controls, and audit.
Accounts used for AI training, inference, and agent orchestration should be individually attributable, least-privileged, and periodically reviewed rather than shared across systems or teams.
SCIM is an IETF HTTP-based protocol for cross-domain identity management that uses standardized schemas and REST operations to create, query, modify, and delete Users and Groups across enterprise, cloud, and SaaS systems. It commonly supports provisioning and deprovisioning; it is not an authentication, SSO, or federation protocol.
Common traps: SCIM is not an authentication or SSO protocol like SAML or OIDC. Federation does not automatically imply account provisioning or deprovisioning.
Distinctions: SCIM = identity provisioning/lifecycle synchronization SAML/OIDC = authentication/federation assertions SCIM does not define its own authentication scheme; deployments rely on TLS and standard HTTP authentication/authorization mechanisms
Authentication systems should correctly implement identity directories, authentication protocols, authenticators, MFA, sessions, recovery, logging, and high availability, with protocol choices matched to risk and assurance requirements.
Authentication architecture should explicitly identify trust relationships among the claimant, authenticator, verifier, IdP/RP, credential store, and session components so one component does not accumulate unnecessary privilege.
A centralized directory or IdP can enforce common MFA, policy, and revocation, but becomes a high-value dependency requiring redundancy, strong administrator protection, and disaster recovery.
Local authentication can keep a system functioning when central identity services are unavailable, but increases risks of password reuse, orphaned accounts, and inconsistent policy.
Prefer modern, supported authentication protocols that resist replay and protect credentials and channels, and retire plaintext or weak challenge-response mechanisms.
A directory service centrally stores users, groups, devices, services, and related attributes and provides an identity foundation for authentication and authorization.
LDAP is used to query and manage directory information and does not by itself imply strong authentication. A plaintext simple bind can expose passwords and should be protected with TLS or another suitable secure channel.
LDAPS commonly refers to LDAP protected by TLS. Modern deployments may also use StartTLS; the key requirement is that TLS protection is actually established and validated.
LDAP simple bind submits a username and password to the directory for verification. Without TLS or equivalent channel protection, those credentials can be exposed.
Replication between directory controllers carries high-value identity and credential-derived data and should authenticate peers, protect transport, and limit replication privileges.
Active Directory integrates directory services, Kerberos, groups, and policy and is often a core enterprise identity dependency. Highly privileged roles such as Domain Admin and domain trusts are high-value security boundaries.
A Domain Controller stores and processes critical identity data and Kerberos key material and should receive the strongest administrator isolation, patching, backup, and monitoring controls.
Kerberos uses shared secrets, tickets, and a trusted KDC to provide network authentication, reduce repeated password transmission, and support SSO.
The Kerberos Key Distribution Center is the central trusted service, normally including the Authentication Service and Ticket Granting Service. KDC compromise can affect the entire realm.
The Kerberos Authentication Service performs initial user authentication and supplies the information needed to issue a Ticket Granting Ticket.
After initial authentication, a user receives a Ticket Granting Ticket and uses it to request service tickets from the TGS without repeatedly sending the user's password to each service.
The Ticket Granting Service validates a TGT and issues a service ticket for the requested target service.
A Kerberos service ticket is presented to a specific service to demonstrate KDC-authenticated identity and establish the relevant session information.
A Kerberos authenticator contains time-related client data used with a ticket to demonstrate freshness and reduce replay of stolen tickets.
Kerberos relies on timestamps for replay resistance. Significant clock skew can cause authentication failure or weaken security, so trustworthy time synchronization is essential.
A Kerberos realm is a trust domain of principals and services managed by a KDC. Cross-realm access requires an explicit trust relationship.
Cross-realm Kerberos trust enables authentication across realms and extends the potential impact of compromise, so trust direction and scope should be carefully controlled.
Pass-the-ticket uses a stolen valid Kerberos ticket to impersonate the ticket holder during its usable lifetime without knowing the plaintext password.
Kerberoasting requests service tickets and performs offline guessing against service-account password-derived keys. Risk comes from weak service-account secrets and protocol/encryption configuration; attack details also intersect Domains 3 and 7.
NTLM is a legacy Windows challenge-response mechanism that lacks some protections of modern Kerberos and is exposed to attacks such as relay and pass-the-hash; dependencies on it should be minimized.
Pass-the-hash abuses a stolen password hash or equivalent credential material directly for authentication in systems that accept that form, without first recovering the plaintext password.
Challenge-response authentication sends a random challenge that the claimant answers using a secret-derived computation, avoiding direct transmission of the secret; the protocol still must resist replay and MITM attacks.
PAP sends a username and password to the peer for verification and provides no strong credential protection by itself; it should be considered only inside an appropriately protected outer channel or similarly controlled context.
CHAP uses a challenge-response mechanism rather than directly sending the password and is stronger than PAP's plaintext model, although modern environments generally have stronger authentication choices.
MS-CHAPv2 has known weaknesses that can enable password recovery and should not be preferred for modern high-assurance remote authentication.
RADIUS commonly centralizes authentication for VPN, 802.1X, and wireless network access and can return authorization attributes; understand the security boundary of classic transport and any additional protections used in deployment.
TACACS+ is commonly used for network-device administrator AAA and supports separate authentication, authorization, and accounting functions, including fine-grained command control.
Domain 5 emphasizes how RADIUS and TACACS+ centralize authentication and authorization. UDP/TCP transport and packet-body protection details are covered more fully in Domain 4.
A smart card can protect a private key or credential and commonly requires a PIN to activate it, combining possession and knowledge factors for strong MFA.
Government and other high-assurance environments commonly use PIV/CAC smart cards for certificate-based authentication and integrated physical/logical access; exact policy varies by environment.
Certificate-based authentication proves control of the private key corresponding to a certificate's public key and depends on PKI, private-key protection, certificate validation, and revocation.
A TLS client certificate can provide strong cryptographic identity for a user or device and is commonly used for mTLS and enterprise-device authentication.
When a device is lost, employment ends, or a private key is compromised, the certificate must become untrusted and verifiers must check CRL, OCSP, or the applicable certificate-status mechanism.
A One-Time Password is valid only once or for a short period, reducing replay risk compared with a static password, but real-time phishing proxies can still relay OTPs.
HOTP generates one-time passwords from a shared secret and an incrementing counter; claimant and verifier must keep counter state sufficiently synchronized.
TOTP generates one-time passwords from a shared secret and the current time window. It is widely used but remains relayable by a real-time phishing proxy.
If the shared HOTP/TOTP seed is stolen, an attacker can generate valid codes. Protect the seed as a long-term secret.
SMS OTP can be defeated through SIM swapping, number hijacking, malicious forwarding, and real-time phishing and generally provides lower assurance than phishing-resistant public-key authenticators.
Push-based MFA sends an approve/deny request to a registered device. It is convenient but exposed to MFA fatigue and accidental approval.
Number matching requires the login session and authenticator to match a displayed or entered number, reducing blind approval of push-bombing requests but not making every deployment completely phishing-resistant.
A hardware OTP token generates one-time codes independently of a phone, reducing mobile-device dependence while still requiring management of token loss, seed protection, and lifecycle.
FIDO2 uses public-key cryptography and origin binding for phishing-resistant authentication and commonly comprises the WebAuthn and CTAP ecosystem.
WebAuthn is a web-platform API that lets relying parties authenticate with public-key credentials while the private key remains in the authenticator and is bound to the RP/origin.
CTAP lets a browser or client communicate with an external or platform FIDO authenticator and is a component of the FIDO2 ecosystem.
A physical security key is a FIDO authenticator that protects a private key and performs origin-bound signatures, providing strong phishing resistance.
A platform authenticator uses device-integrated protection such as a TPM or Secure Enclave for FIDO private keys and can use a PIN or biometric as the activation factor.
A passkey is a user-facing FIDO/WebAuthn credential that can be managed by a platform or security key. Synced passkeys and device-bound credentials have different assurance properties.
A synced passkey can replicate private-key material through a protected ecosystem to multiple devices, improving usability and recovery but differing from AAL3's highest-assurance non-exportable-key requirement.
A device-bound passkey keeps the private key on a specific device or hardware authenticator rather than relying on cross-device synchronization and better supports strict non-exportability requirements.
FIDO credentials are bound to the relying party or origin, so a phishing site cannot normally cause the authenticator to sign for the legitimate site. This makes FIDO more resistant to credential relay than OTP methods.
Even if normal login is phishing-resistant, an account can still be bypassed if recovery relies only on weak SMS verification or help-desk questions. Recovery assurance is part of the authentication system.
Biometric authentication compares physical or behavioral characteristics and is commonly used as an authenticator activation factor or risk signal rather than as a freely revocable secret.
Initial biometric enrollment must occur in a trusted identity and device context; otherwise an attacker may bind their own biometric to another person's account.
Systems normally store a derived biometric template rather than a raw image, but the template remains sensitive data and should be protected and limited to approved purposes.
False Acceptance Rate is the proportion of unauthorized individuals incorrectly accepted by a biometric system; security-sensitive systems generally seek to minimize FAR.
False Rejection Rate is the proportion of legitimate users incorrectly rejected, and excessive FRR harms usability and availability.
Crossover Error Rate or Equal Error Rate is the point near which FAR and FRR are equal and can be used to compare biometric accuracy; a lower value generally indicates better discrimination.
Increasing biometric matching strictness generally lowers FAR while raising FRR, so the threshold should be selected according to the required balance of security and usability.
Liveness detection attempts to confirm that a biometric sample comes from a present live subject rather than a photograph, recording, or replica, reducing spoofing risk.
Biometric characteristics cannot be regenerated like passwords after disclosure, so raw biometric data and templates should not be treated as ordinary revocable secrets.
Behavioral biometrics use patterns such as typing, mouse movement, touch, or gait for ongoing risk decisions and can vary with device, health, or context.
Authentication logging should record success and failure, MFA method, device, source, risk signals, and administrative changes to support anomaly detection and investigation.
Logins from geographically impossible locations within a short interval can indicate compromise, but VPNs, proxies, and mobile networks can produce false positives.
First use of a new device can trigger additional verification and notification, reducing the chance that a stolen password can immediately authenticate from an unknown endpoint.
Authentication-anomaly detection analyzes failure patterns, location, device, time, and behavior to help identify credential stuffing, password spraying, and session abuse.
An adversary-in-the-middle or phishing proxy relays a legitimate login and MFA exchange in real time, potentially stealing the resulting session cookie and demonstrating why ordinary OTP MFA is not fully phishing-resistant.
A stolen session, access, or refresh token may let an attacker bypass another password prompt. Protect token storage, binding, lifetime, and revocation.
Replay-resistant authentication uses nonces, challenges, time, or signatures so captured authentication messages cannot simply be reused.
Public-key authentication lets a verifier store a public key rather than a shared secret that could directly impersonate the user, reducing the impact of verifier credential-database compromise.
Authentication intent requires the user to participate explicitly in the current authentication action, such as touching a security key or entering an activation factor, reducing silent background authentication.
Under current NIST guidance, AAL3 requires phishing-resistant public-key cryptographic authentication with a non-exportable private key. Syncable authenticators do not meet AAL3's non-exportability requirement.
When an IdP or MFA platform fails, use designed secure recovery and break-glass mechanisms rather than broadly bypassing authentication for availability.
Identity services are critical enterprise dependencies and should use redundant directories, IdPs, networks, time services, and key services so the authentication platform is not a single point of failure.
Authentication disaster recovery must include directories, signing keys, MFA configuration, service accounts, and break-glass identities rather than merely restoring server operating systems.
Test successful and failed login, lockout, MFA, recovery, revocation, session timeout, and federation error paths so implementation assurance is not limited to the happy path.
AI can analyze user login, device, and session patterns to detect anomalies and trigger adaptive authentication, but false positives, model drift, and privacy still require governance.
AI agents and automated service accounts should authenticate with verifiable machine identities and short-lived cryptographic credentials rather than impersonating human users or sharing passwords.
Different AI agents, training jobs, and inference services should have distinct identities and credentials so compromise of one agent does not automatically inherit another agent's permissions or audit attribution.