Network Access Control and Zero Trust

Introduction

Network security has traditionally relied on a perimeter model: users and devices inside an organisational network were considered relatively trustworthy, while traffic from outside was treated as suspicious. This model is increasingly inadequate. Cloud services, remote work, mobile devices, contractors, operational technology, and software-defined infrastructure have dissolved the traditional perimeter. A stolen password, compromised endpoint, or misconfigured cloud identity can provide an attacker with legitimate-looking access.

Network access control (NAC) and zero trust address this problem by making access decisions based on identity, device condition, requested resource, context, and policy. They do not eliminate trust; rather, they make trust conditional, limited, observable, and continuously reviewable.

This chapter explains the identity and access technologies used to implement these principles, including authentication, authorisation and accounting (AAA), RADIUS, TACACS+, IEEE 802.1X, multifactor authentication (MFA), privileged access management (PAM), device posture assessment, NAC, and zero-trust architecture.

Learning Objectives

By the end of this chapter, a learner should be able to:

• distinguish identification, authentication, authorisation, accounting, and auditing;
• explain how RADIUS, TACACS+, and 802.1X operate;
• select suitable authentication factors and recognise MFA weaknesses;
• design basic NAC policies using device posture and identity information;
• describe privileged access controls and just-in-time administration;
• apply zero-trust principles to campus, remote, cloud, and hybrid environments;
• evaluate implementation, governance, privacy, and operational challenges.

1. Identity-Based Access and AAA

Access control answers three different questions:

1. Who is requesting access? This is identification.
2. Can the claimant prove that identity? This is authentication.
3. What is the authenticated subject allowed to do? This is authorisation.

A fourth function records what happened. Accounting collects information about sessions, commands, resource usage, and policy decisions. In security operations, these records support auditing, incident response, billing, and compliance.

AAA is therefore a security control and an operational evidence system. A username alone is identification, not authentication. A successful password check authenticates a user but does not automatically authorise access to every application or network segment.

A useful policy model is to grant the minimum access required for a defined task. This is the principle of least privilege. Access should also be denied by default unless a policy explicitly permits it. Exceptions should be documented, time-limited, approved, and reviewed.

Centralised and Federated Identity

An organisation may maintain a central directory such as Active Directory or LDAP, use a cloud identity provider, or federate identity between organisations. Federation allows one organisation to rely on authentication performed by another identity provider. Technologies such as SAML, OpenID Connect, and OAuth 2.0 are common in web and cloud environments, although they serve different roles: SAML and OpenID Connect convey authentication and identity claims, while OAuth 2.0 primarily delegates authorisation.

Centralisation improves consistency and revocation, but it creates dependency and concentration risk. A compromised identity provider may affect many systems. Resilient design therefore requires secure administration, strong recovery procedures, logging, and carefully protected emergency accounts.

2. RADIUS and TACACS+

RADIUS

RADIUS (Remote Authentication Dial-In User Service) is widely used for network access authentication. A network access server (NAS), such as a wireless controller, VPN gateway, or switch, acts as a RADIUS client. It sends an access request to a RADIUS server, which consults an identity store and policy engine. The server returns an Access-Accept, Access-Reject, or Access-Challenge.

RADIUS commonly uses UDP and traditionally protects the password field using a shared secret and protocol-specific processing. This should not be confused with comprehensive encryption of the entire exchange. RADIUS deployments must therefore use strong shared secrets, protected management networks, appropriate transport security where supported, and strict source-address controls. Modern implementations may use RADIUS over TLS (RadSec) to protect the transport.

RADIUS can return authorisation attributes, such as a virtual LAN (VLAN), session timeout, downloadable access control list, or assigned role. This enables identity-based network policy rather than a single static port configuration.

TACACS+

TACACS+ is commonly used for administrative access to routers, switches, firewalls, and other infrastructure. It separates authentication, authorisation, and accounting and encrypts the body of the protocol exchange. This separation supports command-level authorisation, for example allowing an operator to view configuration but preventing them from changing routing or disabling logging.

These are practical tendencies rather than absolute rules. A design should follow the capabilities of the products, protocols, and security requirements in use. Neither protocol removes the need for secure configuration, certificate validation, logging, and resilient server architecture.

3. IEEE 802.1X and Port-Based Admission

IEEE 802.1X provides port-based network access control for wired Ethernet and is also used in enterprise wireless networks. It defines three principal roles:

• Supplicant: the endpoint requesting access;
• Authenticator: the switch or wireless access point controlling access;
• Authentication server: usually a RADIUS server that validates the supplicant.

Before authentication, the authenticator restricts the port to controlled traffic, typically allowing Extensible Authentication Protocol over LAN (EAPOL). The endpoint and authentication server exchange EAP messages through the authenticator. The authenticator does not normally validate the user’s credentials itself; it relays the exchange to RADIUS. If authentication succeeds, the port is authorised and policy attributes may be applied.

Common EAP methods include certificate-based EAP-TLS and tunneled methods that protect inner credentials. EAP-TLS is generally strong because it uses certificates for mutual authentication, but it requires certificate issuance, renewal, revocation, and endpoint supplicant management. Password-based methods can be easier to deploy but are more dependent on secure tunnel validation and user behaviour.

A simplified sequence is:

Figure: The principal message path in an 802.1X deployment.

802.1X is not a complete endpoint security system. A device may authenticate successfully and still be infected, misconfigured, or used by an unauthorised person. For this reason, 802.1X is often combined with posture assessment, segmentation, endpoint detection, and continuous monitoring.

4. Multifactor Authentication

MFA requires two or more independent factor categories:

• Knowledge: something the user knows, such as a password or PIN;
• Possession: something the user has, such as a hardware security key or authenticator device;
• Inherence: something the user is, such as a fingerprint;
• Location or behaviour: contextual evidence, which should normally supplement rather than replace strong primary factors.

Two passwords are not MFA because both are knowledge factors. A password plus a phishing-resistant hardware security key provides stronger independence. Push-based approval can be useful but is vulnerable to fatigue attacks, in which an attacker repeatedly sends prompts until a user accepts one. Number matching, rate limits, risk detection, and user training reduce this risk.

Phishing-resistant methods, including FIDO2/WebAuthn security keys and platform passkeys, bind authentication to the legitimate website or service origin. SMS codes are better than password-only access in some situations but are vulnerable to interception, SIM-swap attacks, and social engineering; they should not be the preferred factor for high-risk administration.

MFA recovery is a major security issue. Help-desk staff must verify identity using procedures that do not allow an attacker who has stolen personal information to bypass the factor. Recovery events should be logged, risk-scored, and reviewed.

5. Privileged Access Management

Privileged accounts can change security controls, create identities, alter systems, or access sensitive data. PAM reduces the risk associated with these accounts through:

• separate administrative accounts rather than using ordinary accounts for administration;
• central vaulting and rotation of privileged credentials;
• just-in-time and just-enough access;
• approval workflows for sensitive operations;
• session recording and command logging;
• strong MFA and device restrictions;
• emergency, or break-glass, accounts with strict monitoring;
• removal of standing local administrator rights where feasible.

Just-in-time access grants privilege only for an approved time window. Just-enough access grants only the permissions required for the task. These controls reduce the duration and scope of a compromise, but they can impede emergency response if approval workflows are poorly designed. Break-glass procedures must therefore be tested, protected, and audited.

Administrative interfaces should be placed on management networks, and privileged sessions should use secure protocols. Shared administrator accounts undermine accountability and should be avoided except where a technical limitation is documented and compensating controls exist.

6. Device Posture Assessment and NAC

NAC combines identity, endpoint information, network enforcement, and policy. A posture assessment may examine:

• operating-system version and security patch level;
• endpoint protection status;
• disk encryption;
• firewall configuration;
• certificate validity;
• device ownership and registration;
• security-agent health;
• jailbreak or root indicators;
• risk signals from endpoint detection systems.

A policy engine can classify a device as compliant, non-compliant, unknown, or high risk. Possible responses include full access, restricted access, a remediation network, quarantine, or denial. The response should be proportional: a device missing a minor update may receive limited access and a remediation path, while a device showing active malware may require isolation.

NAC enforcement can occur at a switch port, wireless controller, VPN gateway, software-defined perimeter, firewall, or cloud policy layer. Common enforcement mechanisms include dynamic VLAN assignment, downloadable ACLs, security-group changes, captive portals, and microsegmentation.

Posture data must be treated carefully. A healthy status is evidence, not proof, because sensors may be disabled, stale, or compromised. NAC should use short assessment lifetimes, telemetry freshness, re-evaluation, and layered controls. It should also provide a safe onboarding process for guests and unmanaged devices without placing them on trusted internal networks.

7. Zero Trust Architecture

Zero trust is an architectural and policy approach in which no user, device, network location, or application is automatically trusted. Access is explicitly requested, evaluated, enforced, and monitored. A practical zero-trust policy asks:

• Which identity or service is requesting access?
• What resource and action are requested?
• Is the device known, managed, and currently healthy?
• What is the sensitivity of the resource?
• What contextual signals exist, such as time, location, network, and recent risk?
• What is the minimum access required?
• How long should the decision remain valid?

The zero-trust concept is often summarised as “verify explicitly, use least privilege, and assume breach.” It is not a single product and does not mean that every packet must be individually reauthenticated. Rather, controls should be placed close to protected resources, and access decisions should be based on current evidence.

A useful logical model is:

Policy decision point (PDP): evaluates identity, device, resource, context, and policy.

Policy enforcement point (PEP): permits, denies, limits, or terminates the connection.

Policy information sources: directory services, endpoint management, threat intelligence, vulnerability systems, certificates, and security analytics.

For example, a user may be permitted to access a payroll application only when using a managed device with current security controls and phishing-resistant MFA. The same identity may be denied from an unmanaged device or required to perform step-up authentication when risk increases.

Zero trust applies to users, devices, workloads, application programming interfaces, and service accounts. In cloud environments, identity and resource policies must be combined with network controls, secrets management, workload identity, logging, and secure configuration. A private IP address or virtual network boundary is not sufficient evidence of trust.

8. Implementation Approach

A diploma-level implementation should proceed in controlled stages:

1. Inventory identities and assets. Identify users, service accounts, endpoints, network devices, applications, data stores, and administrative paths.
2. Classify resources and risk. Mark sensitive systems and identify critical access flows.
3. Strengthen identity. Remove stale accounts, enforce MFA, establish role-based access, and protect recovery processes.
4. Deploy central AAA. Integrate directory services with RADIUS or TACACS+ and ensure resilient logging.
5. Protect network admission. Introduce 802.1X in pilot segments, beginning with managed endpoints and clear exception processes.
6. Add posture and segmentation. Use endpoint management and NAC to distinguish compliant, guest, and risky devices.
7. Control privilege. Implement PAM, separate administrator identities, time-limited elevation, and session accountability.
8. Place enforcement near resources. Use application gateways, firewalls, cloud policies, and microsegmentation.
9. Monitor and improve. Measure denied access, bypasses, stale devices, authentication failures, and policy exceptions.

Availability must be designed from the beginning. RADIUS servers, directories, certificate authorities, and policy engines should have redundancy. Organisations should define fail-open or fail-closed behaviour for different asset classes. A hospital clinical device may require a carefully restricted fail-safe mode, whereas an administrative workstation may appropriately fail closed.

Applied Case: Illustrative Regional College Deployment

Background

A fictional regional college operates wired laboratories, campus Wi-Fi, remote learning services, and a small private cloud. Students, staff, contractors, and visitors share parts of the infrastructure. The college has experienced compromised student accounts and several unmanaged devices connected to laboratory switches.

Problem

The previous design trusted devices connected to internal switch ports. A stolen password allowed VPN access to several internal services, and administrator accounts were shared by the IT team. Logs could show that an account was used but could not reliably identify the individual administrator.

Analysis

The college classified services into public, student, staff, administrative, and restricted research resources. It identified three principal risks: weak authentication, unverified endpoint condition, and excessive standing privilege. It also recognised that a sudden campus-wide enforcement change could disrupt teaching.

Approach and Solution

The college first enabled phishing-resistant MFA for administrators and VPN users, while retaining carefully governed temporary alternatives during enrolment. It deployed TACACS+ for network-device administration and created named administrator accounts. Command authorisation restricted junior staff from changing identity, logging, and firewall policies.

For managed laptops, the college introduced certificate-based 802.1X using EAP-TLS. RADIUS assigned staff and student roles, while unknown devices were directed to a guest or registration network. NAC checked device registration, encryption, endpoint protection, and patch status. Non-compliant devices received remediation access rather than unrestricted internal access.

Administrative access to sensitive applications required a managed device, current posture, MFA, and just-in-time privilege. The college retained emergency accounts in a vault and tested them each term. Logs from RADIUS, directory services, switches, VPN, and PAM were forwarded to a security information and event management platform.

Outcome

The college reduced shared administration, improved attribution, and limited the movement of unmanaged devices. Some laboratory equipment could not support 802.1X, so those devices were placed in restricted segments with compensating firewall rules and monitoring. The college treated this exception as a risk record rather than claiming complete zero trust.

Learning Points

The case demonstrates that zero trust is a staged transformation, not a switch setting. Identity, endpoint condition, enforcement, privilege, logging, availability, and exception management must work together. A technically strong control can still fail if users cannot enrol devices, administrators bypass it, or recovery procedures are unsafe.

Challenges, Ethics, and Governance

Access-control systems process personal and sometimes sensitive information. Device identifiers, locations, authentication events, biometrics, and behavioural signals should be collected for defined purposes, retained only as long as justified, and protected against unauthorised use. Biometrics are particularly sensitive because they cannot be changed like a password.

Policies should be transparent, proportionate, and reviewable. Automated risk decisions may unfairly block users because of inaccurate location data, shared devices, disability-related behaviour, or unusual but legitimate work patterns. Organisations should provide human review and an appeal or recovery route.

Regulatory obligations vary by jurisdiction and sector, but common governance expectations include least privilege, separation of duties, access reviews, incident logging, privacy protection, retention control, and evidence of secure administration. Security teams must also address supply-chain dependencies, including identity providers, managed service providers, endpoint agents, and cloud policy platforms.

Operational challenges include legacy devices, certificate lifecycle errors, inaccurate inventories, user resistance, policy sprawl, alert fatigue, and dependency on central services. Testing should include outages, certificate expiration, directory failure, lost authenticators, compromised administrators, and emergency access.

Contemporary Developments and Best Practices

Passwordless authentication using passkeys is expanding because it can resist phishing while improving usability. Continuous access evaluation uses changing signals, such as token risk or device status, to revoke or restrict access during an active session. Security service edge and software-defined perimeter technologies increasingly deliver identity-aware access across remote and cloud environments.

Artificial intelligence can assist with anomaly detection, account-risk scoring, and policy analysis. It should not be treated as an unquestionable authority. Training-data bias, opaque decisions, adversarial manipulation, and false positives require human governance, explainable evidence, and controlled deployment.

Best practices include:

• prefer phishing-resistant MFA for privileged and high-value access;
• use named accounts and prohibit routine shared administration;
• protect RADIUS, TACACS+, certificates, and shared secrets;
• validate server certificates and maintain certificate lifecycle processes;
• deny by default and grant narrowly scoped, time-limited permissions;
• combine identity with current device posture and resource sensitivity;
• segment guests, unmanaged devices, users, servers, and management traffic;
• log authentication, authorisation, privilege elevation, and policy changes;
• review exceptions and dormant accounts regularly;
• test failure and recovery paths before enforcement;
• measure outcomes rather than merely counting deployed products.

Chapter Summary

Network access control and zero trust replace implicit network trust with explicit, identity-aware and context-aware decisions. AAA separates authentication, authorisation, and accounting. RADIUS is widely used for network access and 802.1X, while TACACS+ is especially useful for administrative device access and command authorisation. 802.1X controls admission through a supplicant, authenticator, and authentication server.

MFA strengthens identity by combining independent factors, with phishing-resistant methods preferred for sensitive access. PAM limits administrative risk through separate accounts, vaulting, just-in-time privilege, approval, and session accountability. Device posture assessment and NAC use endpoint condition to apply full, restricted, guest, remediation, or denied access.

Zero trust is an architectural approach based on explicit verification, least privilege, and an assumption of possible compromise. Effective implementation combines identity, endpoint management, segmentation, application-level enforcement, logging, resilience, privacy governance, and continuous improvement. It is a programme of risk reduction rather than a single product or a claim that trust can be eliminated.

Key Terms

AAA: Authentication, authorisation, and accounting controls.

Accounting: Recording access sessions, actions, and resource use.

Authentication: Verification of a claimed identity.

Authorisation: Determination of permitted actions or resources.

NAC: Network access control that evaluates and enforces endpoint and identity policy.

RADIUS: A protocol commonly used to centralise network access authentication and policy.

TACACS+: A protocol commonly used for centralised administrative access to network devices.

802.1X: Port-based access control using a supplicant, authenticator, and authentication server.

Supplicant: The endpoint requesting network access.

Authenticator: The switch or access point controlling access to a port or wireless connection.

EAP: Extensible Authentication Protocol framework supporting multiple authentication methods.

MFA: Authentication using two or more independent factor categories.

PAM: Controls for managing, limiting, monitoring, and auditing privileged access.

Least privilege: Granting only the access necessary for an authorised task.

Posture assessment: Evaluation of a device’s security condition and compliance.

Microsegmentation: Dividing infrastructure into small security zones with separate policies.

Zero trust: An approach that grants no implicit trust based solely on location or network membership.

Policy enforcement point: A control that permits, denies, limits, or terminates access.

Just-in-time access: Privilege granted only for an approved and limited period.

Break-glass account: A protected emergency account used when normal access mechanisms fail.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation and accounting.
2. What are the three principal roles in an 802.1X deployment?
3. Why are two passwords not considered multifactor authentication?
4. State two advantages of just-in-time privileged access.
5. What is meant by “assume breach” in zero-trust architecture?

Long Answer Questions

1. Compare RADIUS and TACACS+ in terms of purpose, AAA separation, transport, and administrative use.
2. Explain how NAC can use device posture to assign full, restricted, remediation, or denied access.
3. Describe a secure implementation sequence for introducing 802.1X into a mixed campus network.
4. Explain how PAM supports least privilege and accountability for network administrators.
5. Discuss the privacy, availability, and governance challenges of zero-trust implementation.

Analytical / Application Questions

1. A university allows an authenticated user to access every internal server from any device. Analyse the weaknesses in this design and propose a zero-trust replacement.
2. A manufacturing site contains legacy controllers that cannot support 802.1X. Design compensating controls that reduce risk without interrupting production.
3. During an incident, a privileged administrator’s device becomes high risk while a critical service requires urgent repair. Explain how MFA, PAM, break-glass access, logging, and post-event review should be used.

Multiple Choice Questions with Answers

Question 1

Which AAA function determines what an authenticated user is permitted to do?

A. Identification

B. Authentication

C. Authorisation

D. Accounting

Correct Answer: C. Authorisation

Question 2

Which protocol is commonly associated with command-level authorisation for network-device administration?

A. TACACS+

B. DNS

C. HTTP

D. NTP

Correct Answer: A. TACACS+

Question 3

In 802.1X, which component controls the switch port or wireless connection?

A. Supplicant

B. Authenticator

C. Certificate authority

D. Directory user

Correct Answer: B. Authenticator

Question 4

Which is the strongest example of phishing-resistant MFA?

A. Password and PIN

B. Password and SMS code

C. Password and repeated push approvals

D. Password and FIDO2 security key

Correct Answer: D. Password and FIDO2 security key

Question 5

What is the principal purpose of just-in-time privileged access?

A. To create permanent administrator rights

B. To grant privilege only for an approved limited period

C. To remove all logging requirements

D. To replace endpoint security

Correct Answer: B. To grant privilege only for an approved limited period

Question 6

Which response is most suitable for a device that is known but fails a patch-compliance check?

A. Unlimited access to all servers

B. Automatic administrator privileges

C. Restricted remediation access

D. Permanent deletion of the identity directory

Correct Answer: C. Restricted remediation access

Question 7

Which statement best expresses a zero-trust principle?

A. Internal network location automatically proves trust

B. Every user should receive administrator access

C. Access should be explicitly evaluated and limited to need

D. Authentication is unnecessary after VPN connection

Correct Answer: C. Access should be explicitly evaluated and limited to need

Question 8

In a zero-trust architecture, what is the role of a policy enforcement point?

A. It stores all passwords in plain text

B. It applies the permit, deny, or restriction decision

C. It creates vulnerabilities for testing only

D. It replaces every identity provider

Correct Answer: B. It applies the permit, deny, or restriction decision

Question 9

Why are shared administrator accounts undesirable?

A. They improve individual accountability

B. They prevent any configuration change

C. They make attribution and access review more difficult

D. They automatically provide phishing resistance

Correct Answer: C. They make attribution and access review more difficult

Question 10

Which statement about RADIUS security is most accurate?

A. Traditional RADIUS necessarily encrypts every field end-to-end

B. RADIUS requires no shared secret or transport protection

C. RADIUS can support network policy attributes but requires secure deployment

D. RADIUS is used only for physical door locks

Correct Answer: C. RADIUS can support network policy attributes but requires secure deployment