4 Network Authentication

Identity and access

Network authentication verifies that a person, device, or service requesting access is associated with the identity it claims. It answers the question, “Who or what is connecting?” Authentication may take place at a Wi-Fi network, VPN, application, or centralized identity provider.

Authorization is a separate next step: it determines what an authenticated identity is allowed to do. Establishing identity therefore does not, by itself, establish permission for broad access.

Credentials and authentication methods

A credential is information or a device used to prove identity. Authentication methods rely on one or more of three factor categories:

• Something you know: a password or PIN.

• Something you have: a phone, security key, smart card, or device containing a cryptographic key or certificate.

• Something you are: a biometric, such as a fingerprint or face match. In many systems, the biometric locally unlocks a device-held key rather than being sent to the network service.

Two passwords, or a password and a PIN, are still one factor because both are things a person knows. A username identifies an account; it is generally not secret and does not authenticate the user by itself.

Passwords are common, but they can be guessed, reused after a breach, or stolen through phishing. Current NIST guidance calls for passwords used alone to be at least 15 characters. Passwords used as part of MFA may be shorter, but must be at least eight characters. Verifiers should block commonly used or compromised passwords, limit repeated failed attempts, and avoid arbitrary periodic password changes unless a password is compromised or the user requests a change. Passwords are not phishing-resistant.

Other methods have different strengths and risks:

• One-time passcodes (OTPs) are short-lived codes generated by an app or sent to a device. They improve security when combined with another factor, but codes entered by hand can be phished or relayed.

• Push approval sends a prompt to a registered device. Users should approve only sign-ins they initiated; unexpected or repeated prompts may indicate an attack.

• Cryptographic authenticators, including security keys, passkeys, smart cards, and device certificates, prove possession of a private key. Properly implemented public-key methods can provide strong resistance to phishing.

• Network certificates can authenticate a device or user connection in enterprise networks. EAP-TLS is used with 802.1X for Wi-Fi and other network access, using TLS certificate-based authentication.

Multi-factor authentication and strength

Multi-factor authentication (MFA) requires proof from at least two different factor categories. A password and a one-time code from a phone combine “know” and “have”; a password plus a second password does not. A multi-factor authenticator may combine factors internally—for example, requiring a fingerprint or PIN to unlock a security key that then performs a cryptographic operation.

MFA reduces the risk that a stolen password alone will grant access, but methods differ in strength. Manually entered codes and approval prompts can still be targeted by phishing, interception, or push-fatigue attacks. Phishing-resistant cryptographic methods bind authentication to the legitimate service or session, making captured outputs harder to reuse at an impostor site. For sensitive accounts and administrative access, prefer phishing-resistant MFA, such as FIDO-based security keys or passkeys, where available.

Protecting network access

Users can reduce the risk of account compromise by using a unique, long password for each account; a reputable password manager can help create and store them. Enable MFA, preferring a security key or passkey where supported. Never share passwords, one-time codes, or approval requests, and do not approve a sign-in you did not initiate.

Use only official sign-in pages and report unexpected login prompts. If a credential may be exposed, change it and notify the organization. Protect registered devices and report lost or stolen authenticators promptly.

Administrators and organizations should require MFA for remote access, privileged accounts, and other high-impact services. Apply least privilege: successful authentication should not automatically grant broad access. Use approved, protected authentication channels. For enterprise Wi-Fi, EAP-TLS can authenticate a client with a certificate; validate the network’s server certificate so a device does not send credentials to a rogue network.

Issue credentials through a controlled enrollment process. Keep an inventory of authenticators, and revoke or replace them when they are lost, compromised, expired, or no longer needed. Remove accounts promptly when access ends. Store passwords using salted, purpose-built password-hashing methods rather than as readable text, and rate-limit failed attempts. Monitor authentication logs for unusual failures, locations, devices, and repeated MFA prompts.

Protect account recovery methods because weak recovery can undermine strong MFA. Provide secure recovery and backup-authenticator options, and review them when users change roles or leave.