Domain 4 of 5 · Chapter 1 of 8

Logical Security

Encryption in transit vs at rest, and PKI

A medical record copied from a database to a clinician's laptop crosses two danger zones: the wire it travels over and the disk it lands on. Those map to the two states logical security encrypts. Encryption in transit protects data while it moves between hosts; encryption at rest protects it while it is stored. They are independent controls, so encrypting one says nothing about the other, and Network+ scenarios routinely hand you a system that protects one state and leaves the other open.

In transit: TLS and IPsec

Transport Layer Security (TLS) is the dominant in-transit protocol for application traffic: it wraps HTTP into HTTPS, secures email submission, and tunnels TLS/SSL VPNs over TCP 443. Modern guidance (NIST SP 800-52 Rev. 2[1]) requires TLS 1.2 as the minimum and prefers TLS 1.3, while SSL 2.0/3.0 and TLS 1.0/1.1 are obsolete and must not be used. IPsec works one layer lower, protecting whole IP packets, and is the classic choice for site-to-site and remote-access VPN tunnels (see Encryption in transit on the wire in this guide for AH vs ESP detail).

At rest: full-disk and database/object encryption

At-rest encryption renders stored bytes unreadable without a key, so a stolen drive or backup tape yields only ciphertext. Full-disk encryption protects an entire volume; database, file, and object-store encryption protect data inside a running system. The trade-off to remember: at-rest encryption defends against physical theft and offline access, but once a host decrypts data into memory to use it, in-transit and access controls take over.

PKI: who vouches for the key

Public key infrastructure (PKI) is how a verifier trusts a stranger's public key. Every party holds an asymmetric keypair: a private key kept secret and a public key shared freely. A certificate authority (CA) signs an X.509 certificate that binds a public key to a verified identity (a hostname, an organization). A verifier trusts that certificate because a chain of trust runs from it, through any intermediate CAs, up to a root CA already in the verifier's trust store. This is what TLS does during its handshake and what EAP-TLS uses to authenticate 802.1X clients with certificates instead of passwords. A predictable misread: the certificate carries the public key, never the private key, so publishing a certificate exposes nothing secret.

Root CAin trust storeIntermediate CAsigned by rootServer X.509 certidentity + public keysignssignsPrivate key (kept secret)pairs with
PKI chain of trust: a root CA signs an intermediate CA, which signs the server's X.509 certificate binding identity to a public key (private key never leaves the owner).

IAM, AAA, MFA, SSO, and access-control models

Logging into a corporate Wi-Fi, then opening an HR app, then having that action appear in an audit log walks through the whole identity and access management (IAM) lifecycle. The backbone is AAA: authentication (prove who you are), authorization (decide what you may do), and accounting (record what you did). Keep them distinct, because protocols and exam answers split exactly along these lines.

Authentication and MFA factors

Authentication is strongest when it combines factors from different categories. The four Network+ categories are: something you know (password, PIN), something you have (hardware token, smart card, a TOTP code from an authenticator app), something you are (fingerprint, face, other biometrics), and somewhere you are (location, enforced by geofencing). Multi-factor authentication (MFA) means two or more factors from different categories. A password plus a PIN is still single-factor, because both are things you know. Time-based one-time passwords (TOTP) generate a short code that rotates every 30 seconds or so from a shared seed and the current time, giving a "something you have" factor without dedicated hardware.

Authorization: least privilege and RBAC

Once authenticated, authorization decides access. The governing principle is least privilege: grant only the permissions a task needs, nothing more, so a compromised account has a small blast radius. Role-based access control (RBAC) implements this by assigning permissions to roles and users to roles, so access follows job function rather than being granted per person. RBAC is one of several models, summarized below.

Model Who controls policy Exam tell
MAC (mandatory) The system, via labels/clearances "system enforces classification, owner can't override"
DAC (discretionary) The resource owner "owner decides who gets access" (file ACLs)
RBAC (role-based) Roles tied to job function "access keyed to job role"
ABAC (attribute-based) Attributes of subject/object/environment "decision depends on context (device, time, location)"

(NIST SP 800-162[2] defines ABAC; all of these ride on least privilege.)

SSO and federation

Single sign-on (SSO) lets one authentication serve many applications, so users do not re-enter credentials per app. When the apps span organizations or domains, SSO is federated: an identity provider authenticates the user once and asserts that identity to many service providers. SAML is the dominant federation standard for browser-based enterprise web SSO; the directory those flows resolve against is usually LDAP. Geofencing and TOTP layer onto these flows as additional factors or conditions, never as replacements for the authentication step itself.

RequestAuthenticationwho are you?Authorizationwhat may you do?Accountinglog the actionMFA strengthensLeast privilege / RBAC
The AAA pipeline: authentication, then authorization, then accounting, with MFA strengthening the first step and least privilege/RBAC governing the second.

RADIUS, TACACS+, LDAP, and SAML compared

Pick the wrong AAA protocol and the question marks you wrong, because each one is built for a different job. The sharpest contrast on the exam is RADIUS vs TACACS+: both do AAA, but they trade off on transport, encryption, vendor scope, and how they split the three A's.

RADIUS

RADIUS (Remote Authentication Dial-In User Service, RFC 2865[3]) runs over UDP, using authentication port 1812 and accounting port 1813 (legacy deployments used 1645/1646). It is cross-vendor, so it interoperates across mixed hardware, and it is the standard authentication server behind 802.1X and wireless network access. Its key limitation: RADIUS encrypts only the User-Password attribute in the packet, leaving the rest in the clear, and it combines authentication with authorization in a single exchange. That makes it ideal for "is this user allowed onto the network?" but weak for fine-grained, per-command control.

TACACS+

TACACS+ (Terminal Access Controller Access-Control System Plus, RFC 8907[4]) runs over TCP port 49, is Cisco-originated, obfuscates the entire packet body, and separates authentication, authorization, and accounting into independent functions. That separation is exactly what lets it authorize individual administrator commands and log each one, so TACACS+ is the answer for centralized device-administration control on network gear.

LDAP: the directory, not an AAA protocol

LDAP (Lightweight Directory Access Protocol, RFC 4511[5]) is the directory store that holds user and group objects; it answers lookups, it is not itself an AAA protocol. Plain LDAP listens on TCP 389; secured over TLS it becomes LDAPS on TCP 636. RADIUS, SAML, and SSO flows commonly resolve identities against an LDAP directory behind the scenes.

SAML: web SSO federation

SAML 2.0 (Security Assertion Markup Language, an OASIS standard) is the XML, browser-redirect standard for enterprise web SSO. An identity provider authenticates the user and issues a digitally signed assertion that a service provider trusts, carrying authentication plus attributes. It is the right answer when the scenario is "one login across many web applications in a federation," and it travels over HTTPS rather than a dedicated AAA port.

What does the scenario need?RADIUSUDP 1812/1813TACACS+TCP 49SAMLXML web SSOLDAP / LDAPSTCP 389 / 636network accessdevice adminweb SSOdirectory lookupRADIUS = authn+authz combined, password-only encryptionTACACS+ = AAA separated, whole-body obfuscation
Choosing an access protocol by need: RADIUS for network access, TACACS+ for device admin, SAML for web SSO, LDAP/LDAPS as the directory store.

Exam-pattern recognition

Network+ logical-security questions reward matching a one-line scenario to the exact protocol, factor, or control. Train on the patterns below; the right answer almost always hinges on a single distinguishing word in the stem.

Protocol picker

  • "Authenticate wireless/802.1X users against a central, cross-vendor server" → RADIUS (UDP 1812/1813). Distractor TACACS+ is wrong because the scenario is network access, not per-command admin control.
  • "Authorize and log individual administrator commands on Cisco switches" → TACACS+ (TCP 49), because it separates AAA and obfuscates the whole packet. Distractor RADIUS combines authn/authz and encrypts only the password.
  • "One login across many web apps in different organizations" → SAML federation, not LDAP. LDAP is the directory store, not the SSO protocol.
  • "Look up users/groups in the directory" or "secure directory traffic" → LDAP / LDAPS (389 / 636).

Factor and MFA traps

  • Count the categories, not the prompts. Password + PIN = single-factor (both "know"). Password + phone push or TOTP = MFA. Fingerprint + face = single-factor (both "are").
  • "Code that changes every 30 seconds from an app" → TOTP, a "something you have" factor.
  • "Access allowed only from inside the building/region" → geofencing (somewhere you are).

Encryption-state traps

  • "Data encrypted with TLS, but a stolen backup tape is readable" → the gap is at-rest encryption; TLS only covers transit.
  • "Drive encrypted, but credentials sniffed on the network" → the gap is in-transit encryption (TLS/IPsec); disk encryption does not protect the wire.
  • "Certificate published, is the private key exposed?" → no; certificates carry only the public key.

Authorization-model tells

  • "System enforces classification labels, owner cannot override" → MAC.
  • "Resource owner decides who gets access" → DAC.
  • "Permissions follow job role" → RBAC under least privilege.
  • "Decision depends on device, time, or location context" → ABAC.

AAA / access-control protocols compared

PropertyRADIUSTACACS+LDAPSAML
Primary jobAAA (network access)AAA (device admin)Directory lookupWeb SSO federation
Transport / portUDP 1812/1813TCP 49TCP 389 / 636 (LDAPS)HTTP(S) over 443
What it encryptsPassword onlyEntire packet bodyTLS via LDAPSSigned XML assertion
AAA handlingAuthn+authz combinedAuthn/authz/acct separatedNot AAA (store)Authn + attributes
Origin / scopeCross-vendor (RFC 2865)Cisco (RFC 8907)Cross-vendor (RFC 4511)OASIS standard

Decision tree

What does the scenario need?logical security controlProtect the datatransit or rest?Network accesswho gets on?Device adminper-command?One login,many web appsconfidentiality802.1X / Wi-Fiadmin controlfederationTLS / IPsec+ at-rest encryptionRADIUSUDP 1812/1813TACACS+TCP 49SAML SSOLDAP as directoryAlways: enforce MFA + least privilege (RBAC) on top of any choice

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Encrypt data in both transit and at rest, they are separate layers

Encryption in transit protects data while it crosses the network and encryption at rest protects it while stored on disk, and the two are independent controls. A system can secure one and leave the other open, so TLS on the wire does nothing for a stolen backup tape, and full-disk encryption does nothing for credentials sniffed off the network. Always confirm which state the scenario is actually leaving exposed.

Trap Assuming TLS or HTTPS also protects stored data; it only covers the wire, so at-rest encryption is still needed on disk and backups.

2 questions test this
TLS secures application traffic in transit; require 1.2+ and prefer 1.3

TLS is the dominant in-transit protocol, wrapping HTTP into HTTPS and tunneling TLS/SSL VPNs over TCP 443. NIST SP 800-52 Rev. 2 requires servers to support TLS 1.2 as the minimum and to prefer TLS 1.3, while SSL 2.0/3.0 and TLS 1.0/1.1 are obsolete and must not be used. TLS 1.3 completes its handshake in one round trip and makes forward secrecy mandatory.

Trap Allowing TLS 1.0/1.1 or SSL 3.0 as still acceptable; all are deprecated and fail modern configuration baselines.

1 question tests this
PKI binds an identity to a public key through a CA-signed X.509 certificate

Public key infrastructure issues X.509 certificates that pair a public key with a verified identity, and a certificate authority (CA) signs each one. A verifier trusts the certificate because a chain of signatures runs from it, through any intermediate CAs, up to a root CA already in its trust store. This same chain-of-trust model underpins TLS, EAP-TLS, and code signing.

A keypair splits into a private key you guard and a public key you share

Asymmetric cryptography gives each party a private key kept secret and a public key distributed freely, and an X.509 certificate carries only the public key. Publishing a certificate therefore exposes nothing secret, because the private key never leaves the owner. Anyone can encrypt to or verify a signature from the public key, but only the private-key holder can decrypt or sign.

Trap Believing a published certificate leaks the private key; the certificate contains only the public key, so the private key stays protected.

AAA is three distinct steps: authentication, authorization, accounting

Identity and access management runs on AAA: authentication proves who you are, authorization decides what you may do, and accounting records what you did. These are separate concerns, and exam answers split along the same lines, so passing authentication does not by itself grant any access. A protocol or control usually targets one or two of the three, not all interchangeably.

Trap Treating successful authentication as authorization; proving identity does not decide what the user is permitted to do.

MFA needs factors from different categories, not just multiple prompts

Multi-factor authentication combines two or more factors from distinct categories: something you know (password, PIN), something you have (token, smart card, TOTP app), something you are (biometric), and somewhere you are (location). Two factors from the same category are still single-factor, so a password plus a PIN is single-factor because both are things you know, and a fingerprint plus a face scan is single-factor because both are things you are. Count categories, not the number of prompts.

Trap Counting password plus security question as MFA; both are something you know, so it remains single-factor.

3 questions test this
TOTP gives a something-you-have factor from a rotating code

A time-based one-time password (TOTP) derives a short code from a shared seed and the current time, rotating roughly every 30 seconds. It supplies a something you have factor without dedicated hardware, since the authenticator app holds the seed. On the exam, a code that changes every 30 seconds from an app is TOTP, a possession factor, not a knowledge factor.

Geofencing is the somewhere-you-are factor

Geofencing restricts or conditions access based on physical location, enforcing the somewhere you are factor. It can require that a login originate from inside a building, campus, or country before access is granted. It adds context to authentication rather than replacing the identity-proving step.

Least privilege grants only the access a task requires

Least privilege means giving each user or process only the permissions its job needs and nothing more, which shrinks the blast radius of a compromised account. It is the principle every access-control model rides on, including RBAC, MAC, DAC, and ABAC. Combine it with MFA so a stolen password alone cannot reach much.

RBAC ties permissions to roles, so access follows job function

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles, so access follows job function rather than being granted per individual. It implements least privilege at scale because adding or removing a person is a role change, not a permission audit. The exam tell is access keyed to a job role.

Trap Confusing RBAC with ABAC; RBAC keys access to job roles, while ABAC decides on contextual attributes like device, time, or location.

4 questions test this
Access-control models differ on who controls the policy

MAC is enforced by the system against labels and clearances and cannot be overridden by the owner, DAC lets the resource owner grant access at their discretion (file ACLs), RBAC ties permissions to job roles, and ABAC decides on attributes of the subject, object, action, and environment. The exam tells: system enforces classification and owner cannot override is MAC, owner decides sharing is DAC, access keyed to job function is RBAC, and decision depends on context is ABAC. All four ride on least privilege.

Trap Calling owner-controlled file permissions mandatory access control; owner discretion is DAC, while MAC is system-enforced via labels the owner cannot change.

SSO lets one authentication serve many applications

Single sign-on (SSO) authenticates the user once and grants access to many applications without re-entering credentials, reducing password fatigue. When the apps span organizations, SSO is federated: an identity provider asserts the user's identity to many service providers. SSO is a convenience and consistency layer over authentication, not an authorization model.

1 question tests this
SAML is the XML standard for enterprise web SSO federation

SAML 2.0, an OASIS standard, is the XML browser-redirect protocol for enterprise web single sign-on. An identity provider authenticates the user and issues a digitally signed assertion that a service provider trusts, carrying authentication plus attributes over HTTPS rather than a dedicated AAA port. Choose SAML when the scenario is one login across many web applications in a federation.

Trap Picking LDAP for cross-organization web SSO; LDAP is the directory store the flow resolves against, while SAML is the federation protocol.

3 questions test this
RADIUS does AAA over UDP and encrypts only the password

RADIUS (RFC 2865) runs over UDP using authentication port 1812 and accounting port 1813 (legacy 1645/1646), is cross-vendor, and is the standard authentication server behind 802.1X and wireless access. It encrypts only the User-Password attribute in the packet and combines authentication with authorization in one exchange. That makes it ideal for is this user allowed onto the network but weak for fine-grained per-command control.

Trap Assuming RADIUS encrypts the whole packet; only the User-Password attribute is hidden, leaving the rest in cleartext.

5 questions test this
TACACS+ runs over TCP 49, separates AAA, and obfuscates the whole body

TACACS+ (RFC 8907) runs over TCP port 49, is Cisco-originated, obfuscates the entire packet body, and separates authentication, authorization, and accounting into independent functions. That separation is what lets it authorize and log individual administrator commands, so it is the answer for centralized device-administration control on network gear. Reach for it when per-command authorization or full-payload protection matters.

RADIUS vs TACACS+: network access vs device administration

RADIUS uses UDP (1812/1813), is cross-vendor, encrypts only the password, and combines authn with authz, fitting 802.1X and wireless network access. TACACS+ uses TCP 49, is Cisco-originated, obfuscates the whole body, and separates the three A's, fitting granular administrator command control on network devices. Match the stem: get-onto-the-network is RADIUS, authorize-each-admin-command is TACACS+.

Trap Choosing RADIUS to authorize individual admin commands; it combines authn/authz and encrypts only the password, so TACACS+ with separated AAA is the fit.

LDAP is the directory store, not an AAA protocol

LDAP (Lightweight Directory Access Protocol, RFC 4511) holds user and group objects and answers directory lookups; it is not itself an AAA protocol. Plain LDAP listens on TCP 389, and secured over TLS it becomes LDAPS on TCP 636. RADIUS, SAML, and SSO flows commonly resolve identities against an LDAP directory behind the scenes.

Trap Treating LDAP as the single sign-on protocol; it is the backing directory, while SAML or another federation protocol performs the SSO.

802.1X authenticates a port or SSID before passing general traffic

IEEE 802.1X is port-based network access control that gates a wired switch port or wireless SSID before an IP address is issued, using a supplicant (client), an authenticator (switch or AP), and an authentication server (typically RADIUS). The supplicant and authenticator exchange EAP over the LAN and the authenticator relays credentials to the RADIUS server. EAP-TLS within this flow uses client certificates for the strongest mutual authentication.

3 questions test this
IPsec secures whole IP packets for VPN tunnels

IPsec protects data in transit at the IP layer and is the classic choice for site-to-site and remote-access VPN tunnels, encrypting whole packets with ESP. A TLS/SSL VPN over TCP 443 is the alternative when you need clientless, NAT-friendly access through firewalls. Pick IPsec for gateway-to-gateway tunnels and a TLS VPN when browser-based or firewall-traversal access is the priority.

1 question tests this
Authorization decides access only after authentication succeeds

Authentication and authorization are sequential and distinct: the system first verifies identity, then a separate step decides what that verified identity may do. A user can be correctly authenticated yet authorized for nothing, and a permission change never re-proves identity. Keeping them separate is why TACACS+ can authorize each command independently of the initial login.

Also tested in

References

  1. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
  2. NIST SP 800-162 — Guide to Attribute Based Access Control (ABAC) Definition and Considerations Whitepaper
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS) Whitepaper
  4. RFC 8907 — The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol Whitepaper
  5. RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol Whitepaper