Study guide
5.1 Implement and Maintain Authentication Methods
ISC2 Systems Security Certified Practitioner SSCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction and Exam Overview
1.1 Current Exam Facts 1.2 Computerized Adaptive Testing, Scoring, and Retakes 1.3 Eligibility, Associate Pathway, Endorsement, and Maintenance
2 Ethics and Security Concepts
2.1 Comply with Codes of Ethics 2.2 Understand Security Concepts 2.3 Identify and Implement Security Controls
3 Functional Controls, Assets, and Change Management
3.1 Document and Maintain Functional Security Controls 3.2 Support and Implement the Asset Management Lifecycle 3.3 Support and Implement the Change Management Lifecycle
4 Security Awareness and Physical Security Operations
4.1 Support and Implement Security Awareness and Training 4.2 Collaborate with Physical Security Operations
5 Authentication Methods and Trust Architectures
5.1 Implement and Maintain Authentication Methods 5.2 Federated Access with OAuth2, SAML, and OpenID Connect 5.3 Understand and Support Internetwork Trust Architectures
6 Identity Lifecycle and Access Control Models
6.1 Support and Implement the Identity Management Lifecycle 6.2 Mandatory, Discretionary, and Role-Based Access Control 6.3 Rule-Based, Attribute-Based, and Privileged Access Management
7 Risk Management, Visibility, and Legal Concerns
7.1 Risk Management Concepts and Treatment 7.2 Risk Visibility, Reporting, and Threat Intelligence 7.3 Legal and Regulatory Concerns
8 Assessments, Monitoring, and Analysis
8.1 Security Assessments and Vulnerability Management 8.2 Operate and Monitor Security Platforms 8.3 Analyze Monitoring Results
9 Incident Response and Forensic Investigations
9.1 Incident Response: Preparation, Detection, Analysis, and Escalation 9.2 Containment, Eradication, Recovery, and Lessons Learned 9.3 Understand and Support Forensic Investigations
10 Business Continuity and Disaster Recovery
10.1 Business Continuity and Emergency Response 10.2 Disaster Recovery and Restoration Metrics 10.3 Backup, Redundancy, Testing, and Drills
11 Cryptography Foundations
11.1 Reasons and Requirements for Cryptography 11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC 11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis
12 Secure Protocols and Public Key Infrastructure
12.1 Understand and Implement Secure Protocols 12.2 Understand Public Key Infrastructure
13 Networking Fundamentals, Attacks, and Access Controls
13.1 Understand and Apply Fundamental Concepts of Networking 13.2 Understand Network Attacks and Countermeasures 13.3 Manage Network Access Controls
14 Network Security Operations, Wireless, and IoT
14.1 Manage Network Security 14.2 Operate and Configure Network-Based Security Appliances and Services 14.3 Secure Wireless Communications 14.4 Secure and Monitor Internet of Things
15 Malware, Malicious Activity, and Endpoint Security
15.1 Identify and Analyze Malicious Code 15.2 Malicious Activity, Social Engineering, and Behavior Analytics 15.3 Implement and Operate Endpoint Device Security
16 Mobile, Cloud, and Virtual Environments
16.1 Administer and Manage Mobile Devices 16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility 16.3 Cloud Legal, Regulatory, and Third-Party Requirements 16.4 Operate and Maintain Secure Virtual Environments
5.1 Implement and Maintain Authentication Methods
Key Takeaways Explain This Topic AI
Multi-factor authentication (MFA) requires two or more different factor types — something you know, have, are, do, or somewhere you are — not two passwords or a password plus a personal identification number (PIN).
Phishing-resistant MFA uses Fast Identity Online 2 (FIDO2) / Web Authentication (WebAuthn) passkeys or smart-card certificates bound to the real origin; Short Message Service (SMS), email one-time passwords, and one-tap push are not phishing-resistant.
Push-fatigue (MFA bombing) is an attacker with a stolen password flooding approve prompts until the user taps Allow; number matching, rate limits, and hardware-backed authenticators close that path.
Single sign-on (SSO) with Active Directory Federation Services (ADFS) or OpenID Connect (OIDC) authenticates once at the identity provider; that identity provider is a crown-jewel system, not a way to skip MFA.
Device authentication proves the endpoint (machine certificate, Trusted Platform Module); a Media Access Control (MAC) address is a spoofable label and is not equivalent to a cryptographic device credential.
Last updated: August 2026
Why authentication is an operations job
Domain 2, Access Controls , is weighted at 15% of the Systems Security Certified Practitioner ( SSCP ) exam under the outline effective 1 October 2025. Knowledge area 2.1 — Implement and maintain authentication methods — is not a vocabulary quiz about passwords. You will configure multi-factor authentication (MFA) , single sign-on (SSO) with Active Directory Federation Services (ADFS) or OpenID Connect (OIDC) , and device authentication using certificates, Media Access Control (MAC) addresses, or a Trusted Platform Module (TPM) . You will also keep those methods from rotting: exception lists, push-fatigue, Short Message Service (SMS) fallback, and MAC filters that an intern can spoof.
Authentication is proving a claimed identity. Identification is presenting the claim (username, badge number, device name). Authorization is what that identity is allowed to do after it is authenticated. Domain 2 tests all three, but 2.1 is the proof step. A perfect role-based access model fails if the proof is a shared password, a phishable SMS code, or a MAC address copied from ipconfig .
The exam stem is usually an operations ticket: a vice president wants MFA disabled for travel, a warehouse wants scanners on wireless with "MAC lock," or a cloud team wants SSO so users stop hoarding local passwords. Your job is to pick a method that actually proves the user or the device, and then maintain it after the first successful login.
Authentication factors: know, have, are, do, somewhere
Exam items still use the classic factor types. MFA means two or more different types , not two secrets of the same type.
Factor Nickname Operational examples Typical failure
Something you know Knowledge Password, personal identification number (PIN) , passphrase, security questions Phishing, reuse, spray, shoulder-surfing
Something you have Possession Hardware token, smart card, phone authenticator, Fast Identity Online 2 (FIDO2) security key, one-time password (OTP) fob Theft, SIM swap, token cloning, MFA fatigue on push apps
Something you are Inherence Fingerprint, face, iris, voiceprint Presentation attack, injured/unreadable biometric, mishandled templates
Something you do Behavior Keystroke dynamics, gait, mouse patterns High false-accept or false-reject; rarely sufficient alone
Somewhere you are Location Source network, geofence, Impossible Travel, office virtual local area network (VLAN) Virtual private network (VPN) exit-node spoofing; location is a signal, not a secret
A password plus a PIN is still one type (knowledge). A password plus an authenticator-app OTP is two types (know + have). A fingerprint that unlocks a laptop which then also requires the disk PIN is inherence plus knowledge. Adaptive authentication can step up factors when risk is high — new device, new country, privileged application — without forcing a hardware key on every intranet wiki.
Something you do and somewhere you are usually show up as supporting signals, not as standalone logons. A bank that blocks a wire from a country the customer has never visited is using location as a risk control. It is not a replacement for MFA. On a CAT item, if the stem gives only a geofence, do not call that multi-factor.
Single-factor versus MFA — and why SMS is not good enough
Single-factor authentication is still common for low-risk kiosks, badge-only doors that a camera covers, and break-glass paths that you then monitor. The SSCP expectation for remote access, email, privileged workstations, and cloud consoles is MFA.
Maintain MFA; do not only turn it on. Watch the methods:
SMS and voice OTP are possession factors in theory and phishable codes in practice. Subscriber Identity Module (SIM) swap and Signaling System 7 ( SS7 ) interception steal the second factor. Convenient fallback; not phishing-resistant.
Email OTP is a second copy of mailbox access. Whoever already reads the inbox gets the code.
Time-based OTP apps are better than SMS and still phishable in real time through an adversary-in-the-middle proxy that relays the code.
Push notifications are easy for users and are abused by push-fatigue (also called MFA bombing or MFA fatigue). The attacker who already has the password floods Approve prompts until a tired technician taps Allow at 2 a.m. Mitigate with number matching (the user types a code shown on the login screen), context (app name, geography), rate limits, and a one-tap "I did not request this" report that pages the Security Operations Center (SOC) .
Phishing-resistant MFA uses FIDO2 / Web Authentication (WebAuthn) passkeys and security keys, or smart-card / Personal Identity Verification (PIV) certificates. The authenticator is bound to the origin — the real hostname of the login site — so a fake VPN portal cannot harvest a reusable OTP.
- Method Factor types Phishing-resistant? Operations note
- Password only Know No Single-factor
- Password + SMS OTP Know + have No SIM swap; phishable codes
- Password + one-tap push Know + have No, unless number matching and origin checks Fatigue attacks
- Password + time-based OTP app Know + have No Real-time phishing kits
FIDO2 passkey or security key Have, often gated by biometric or PIN Yes Origin-bound; no shared secret to phish
Smart card / PIV + PIN Have + know Yes when certificate-backed Needs enterprise public key infrastructure and readers
If an executive demands "disable MFA for travel," treat that as an exception you must maintain : time-bound, logged, compensating monitoring, and a return date. Permanent VIP exclusions are how business email compromise starts. The same rule applies to service accounts that "cannot do MFA" — give them a certificate or a vaulted credential with no interactive login, not a shared password in a wiki.
Single sign-on: ADFS and OpenID Connect
SSO lets a user authenticate once to an identity provider (IdP) and then reach many applications without a new password prompt for each one. The SSCP outline's examples are ADFS and OpenID Connect .
ADFS is Microsoft's on-premises federation service. It commonly issues Security Assertion Markup Language (SAML) or WS-Federation tokens to relying parties, using Active Directory as the account store. You maintain ADFS like any authentication service: patch the farm, protect the token-signing certificate, restrict the admin console, monitor failed authentications, and plan certificate rollover before the signing cert expires on a Sunday.
OpenID Connect is an identity layer on Open Authorization 2 (OAuth2) . It authenticates the user and returns an ID token (usually a JSON Web Token (JWT) ) plus optional access tokens. Cloud IdPs speak OIDC natively. A practitioner who "turns on SSO" still has to register the application, set redirect Uniform Resource Identifiers, map claims ( employeeId , groups), and refuse the vendor's offer to store a directory password.
SSO improves usability and can improve security: one strong MFA at the IdP beats twenty weak local passwords. It also concentrates risk. If the IdP is phished, every connected app is in play. Protect the IdP with phishing-resistant MFA, device-aware conditional access, and a handful of break-glass accounts that are monitored and stored offline. SSO is not a reason to skip MFA; it is the place you enforce MFA once, well.
Device authentication versus user authentication
User authentication proves the person (or the service identity) at the keyboard or API. Device authentication proves the endpoint is a known, healthy machine. A valid user on an unmanaged personal phone is a different risk from that user on a corporate laptop with a TPM and a current compliance attestation. Knowledge area 2.1 tests both, and the outline's device examples are certificate, MAC address, and TPM.
Certificate-based device authentication : a machine certificate from the enterprise public key infrastructure (PKI) , used in IEEE 802.1X , IPsec, or VPN. Generate and store the private key in the TPM so it cannot walk away with a copied user profile.
MAC address : the 48-bit Layer 2 identifier. Switches and wireless controllers can allowlist MACs. This is identification more than authentication. MACs are not secret, not signed, and trivial to spoof with ifconfig , a driver utility, or a USB network adapter.
TPM : a hardware root of trust. It holds keys, can measure boot (attestation), and can back full-disk encryption. A TPM-backed credential survives a stolen disk image in a way that a software certificate file does not.
Device proof does not replace user proof. A stolen laptop with a valid machine certificate is still a stolen laptop. Combine device authentication with user MFA, certificate revocation, and the ability to mark the device non-compliant in network access control.
Scenario: MAC spoofing as weak device authentication
You are the network engineer for a warehouse. The wireless controller uses MAC filtering so "only scanners can join SSID WAREHOUSE." A contractor copies a scanner's MAC from the sticker on the battery door, sets that address on a laptop, and associates. The controller treats the laptop as a trusted device. There is no user MFA, no machine certificate, and no TPM check. The contractor now sits on the same segment as inventory controllers.
That incident is the exam's device-authentication trap. MAC filtering is a coarse filter, not proof of a device. Prefer 802.1X with machine certificates, check device compliance (patch level, disk encryption, endpoint detection) before issuing a network authorization, and still require the person to authenticate as themselves. Maintain device identity the same way you maintain user identity: inventory, certificate lifetime, revocation when a scanner is wiped or stolen, and a ticket when a MAC allowlist is the only control left on a legacy line.
Putting 2.1 together
When a stem describes a login, name the factors, say whether they are independent types, and say whether the proof is of a user, a device, or both. Prefer phishing-resistant MFA for privileged and remote paths. Treat SSO as an IdP you must harden, not as a password you can forget. Treat MAC addresses as labels. Treat TPM-backed certificates as real device credentials. And remember the maintain half of the objective: fatigue settings, exception reviews, expired machine certificates, and ADFS signing-certificate rollover are how authentication actually fails on a Tuesday night.