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.
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.
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.
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
| Property | RADIUS | TACACS+ | LDAP | SAML |
|---|---|---|---|---|
| Primary job | AAA (network access) | AAA (device admin) | Directory lookup | Web SSO federation |
| Transport / port | UDP 1812/1813 | TCP 49 | TCP 389 / 636 (LDAPS) | HTTP(S) over 443 |
| What it encrypts | Password only | Entire packet body | TLS via LDAPS | Signed XML assertion |
| AAA handling | Authn+authz combined | Authn/authz/acct separated | Not AAA (store) | Authn + attributes |
| Origin / scope | Cross-vendor (RFC 2865) | Cisco (RFC 8907) | Cross-vendor (RFC 4511) | OASIS standard |
Decision tree
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.
- 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
- A security administrator is implementing multi-factor authentication for remote VPN users. Which of the following credential combinations…
- A data center requires two-factor authentication for physical entry. Staff must tap a proximity card and then scan a fingerprint before the…
- A network administrator configures VPN access to require a password and a one-time code from a hardware token. Which of the following…
- 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
- A company uses NAC to authenticate users on the corporate wireless network and assign them to VLANs based on their organizational role.…
- A company wants its help desk staff to reset user passwords and unlock accounts while preventing them from changing switch or firewall…
- A network administrator needs to ensure that junior technicians can only view device configurations while senior engineers have full…
- A company requires that network administrators have full access to manage switches and routers, while helpdesk staff can only view device…
- 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.
- 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
- A company deploys SAML so that employees authenticate once at a corporate login page and then access multiple cloud applications without…
- A company needs employees to authenticate once with the corporate identity provider and then seamlessly access multiple cloud-based…
- A company deploys SAML-based SSO so employees can access multiple cloud applications using a single login. Which of the following…
- 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
- An enterprise deploys 802.1X authentication on its switches integrated with a RADIUS server. When employees authenticate, the RADIUS server…
- An organization deploys 802.1X authentication and wants employees from different departments to be automatically placed on separate VLANs…
- After deploying 802.1X on all switch ports, a network engineer wants authenticated users to be dynamically placed into VLANs based on their…
- A hospital uses 802.1X authentication so that clinical staff are dynamically placed on the medical VLAN and administrative staff are placed…
- A firewall administrator needs to permit RADIUS authentication traffic between a wireless controller and the authentication server. Which…
- 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
- An enterprise deploys 802.1X authentication on its switches integrated with a RADIUS server. When employees authenticate, the RADIUS server…
- In an 802.1X port-based network access control deployment, which of the following describes the role of the authenticator?
- In an 802.1X port-based NAC deployment, which of the following is responsible for relaying EAP messages between the endpoint and the RADIUS…
- 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.
- 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
- SAP-C02 AWS Certified Solutions Architect - Professional
- AZ-900 Microsoft Azure Fundamentals
- SY0-701 CompTIA Security+
- PCA Professional Cloud Architect
- CCSP Certified Cloud Security Professional
- CCSP Certified Cloud Security Professional
- CC Certified in Cybersecurity
- CC Certified in Cybersecurity
- CISSP Certified Information Systems Security Professional
- CISSP Certified Information Systems Security Professional
References
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
- NIST SP 800-162 — Guide to Attribute Based Access Control (ABAC) Definition and Considerations Whitepaper
- RFC 2865 — Remote Authentication Dial In User Service (RADIUS) Whitepaper
- RFC 8907 — The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol Whitepaper
- RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol Whitepaper