5.1 Implement and Maintain Authentication Methods

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.

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.

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.