Chapter 3: Scenarios & Selection

Eight real-world deployment scenarios with descriptions, key technical metrics, and selection guidance

Network identity authentication requirements vary significantly across deployment environments. This chapter presents eight canonical scenarios drawn from enterprise deployments, each with a photorealistic scene, detailed description, key technical indicators, and selection criteria. Understanding these scenarios enables architects to match the correct authentication mechanism, enforcement model, and policy design to each environment's unique risk profile and operational constraints.

Scenario 1: Wired Enterprise LAN — 802.1X EAP-TLS

Wired 802.1X EAP-TLS Deployment
Figure 3.1: Wired Enterprise LAN — Managed workstations authenticate via EAP-TLS certificates through access switches to RADIUS server, with dynamic VLAN assignment

In a wired enterprise LAN, all managed workstations connect via Ethernet to access switches in IDF closets. Each workstation holds a machine certificate issued by the corporate PKI, enabling EAP-TLS mutual authentication. The switch acts as the 802.1X authenticator, forwarding EAP frames to the RADIUS server, which validates the certificate chain and revocation status before returning a VLAN/ACL assignment. Devices without valid certificates are placed in a remediation VLAN where they can access only the MDM and CA proxy for certificate enrollment.

Auth Protocol
EAP-TLS (mutual)
RADIUS p95 Latency
< 800 ms
Auth Success Rate
≥ 99%
OCSP Response
< 300 ms p95
Fallback Behavior
Remediation VLAN
Cert Renewal Lead
14–30 days
Technical IndicatorTarget ValueNotes
EAP-TLS coverage100% managed endpointsNo PEAP-MSCHAPv2 in production zones
Dynamic VLAN assignmentPer-role, per-deviceRADIUS attribute: Tunnel-Private-Group-ID
MAB fallback (legacy)Restricted ACL onlyDocumented exception with expiry date
RADIUS cluster HAN+1 active-activeFailover < 30 s; site survivability for WAN failure
Certificate key sizeRSA 2048+ or ECDSA P-256Enforced via CA template EKU constraints

Scenario 2: Enterprise Wi-Fi — Multi-SSID Role-Based Access

Enterprise Wi-Fi Multi-SSID Deployment
Figure 3.2: Enterprise Wi-Fi — Three SSIDs (Corporate EAP-TLS, BYOD Enrollment, Guest Captive Portal) with RADIUS dynamic VLAN assignment via wireless controller

Enterprise wireless deployments typically require three distinct SSIDs serving different user populations. The corporate SSID uses EAP-TLS with machine certificates for managed devices, providing seamless roaming and dynamic VLAN assignment. A BYOD enrollment SSID provides a limited-access path for personal devices to enroll certificates via SCEP/MDM. A guest SSID redirects unauthenticated users to a captive portal with sponsor approval workflow. The wireless controller acts as the central enforcement point, applying RADIUS-returned VLAN assignments to all associated clients.

Roam Interruption
< 150 ms
SSID Count
3 (Corp/BYOD/Guest)
BYOD Onboard Time
< 5 min
Guest Session TTL
4–8 hours
WLC HA
Active-Standby
AP Coverage
-67 dBm minimum
SSIDAuth MethodVLAN AssignmentAccess Level
CorporateEAP-TLS (machine cert)Dynamic per roleFull corporate access per policy
BYOD EnrollmentPEAP-MSCHAPv2 (temp)Enrollment VLAN onlyMDM/CA proxy only; cert issued then migrated
GuestCaptive portal + sponsorGuest VLANInternet only; DNS filtered; rate limited

Scenario 3: IoT Device Tiered Onboarding and Containment

IoT Device Tiered Onboarding
Figure 3.3: IoT Device Containment — NAC profiling engine classifies IP cameras, printers, badge readers, and environmental sensors into dedicated VLANs; unknown devices quarantined automatically

IoT devices — IP cameras, printers, badge readers, environmental sensors — cannot run 802.1X supplicants and require an alternative onboarding model. NAC profiling uses DHCP fingerprinting, SNMP OID matching, HTTP user-agent analysis, and API integrations with asset management systems to classify devices automatically. Each device type is assigned to a dedicated IoT VLAN with a restrictive ACL permitting only the specific ports and destinations required for its function. Unknown devices are automatically placed in a quarantine VLAN pending manual review or automated remediation.

Profiling Accuracy
> 95%
Quarantine Time
< 60 s
IoT VLAN Count
4–8 per site
ACL Specificity
Port + destination
CoA Trigger
On profile change
Exception Review
Monthly cycle
Device TypeProfiling SourceAssigned VLANACL Restrictions
IP CameraDHCP + HTTP UACamera VLANAllow only NVR server; deny all else
Network PrinterDHCP + SNMP OIDPrinter VLANAllow print ports; deny internet
Badge ReaderDHCP + MAC OUIAccess Control VLANAllow only access control server
Environmental SensorDHCP + APISensor VLANAllow only BMS/SCADA server
UnknownNo matchQuarantine VLANDeny all; alert to SIEM

Scenario 4: Visitor and Guest Network Management

Guest Network Management
Figure 3.4: Guest Network — QR code captive portal with sponsor approval workflow; guest VLAN provides internet-only access with DNS filtering, rate limiting, and session expiry

Guest network management must balance hospitality with security. Visitors scan a QR code at reception, which redirects their device to a captive portal requiring either a sponsor approval or a self-service registration with legal notice acceptance. The guest VLAN is strictly isolated from the corporate network at the firewall level, with DNS filtering to block malicious domains, bandwidth rate limiting to prevent abuse, and automatic session expiry to prevent credential sharing. Sponsor approval workflows integrate with email or ITSM systems for accountability.

Onboard Time
< 2 min
Session Duration
4–8 hours max
Bandwidth Cap
10 Mbps per user
DNS Filter
Category-based
Corporate Access
Zero (deny-all)
Sponsor Approval
Email + ITSM
ControlImplementationPurpose
Captive portalNAC-hosted; HTTPS redirectCollect identity and legal consent
Sponsor approvalEmail link or ITSM ticketAccountability for guest access
VLAN isolationFirewall deny-all to corporatePrevent lateral movement
DNS filteringCategory-based block listBlock malware/phishing domains
Rate limitingPer-user bandwidth policyPrevent bandwidth abuse
Session expiryAutomatic after TTLPrevent credential sharing

Scenario 5: Remote Workforce — MFA + ZTNA Conditional Access

Remote Workforce ZTNA
Figure 3.5: ZTNA Conditional Access — Remote users authenticate through IdP MFA/CA with risk scoring, device compliance check, and geo/IP reputation before accessing per-app internal segments

Remote workforce access requires continuous verification of user identity, device health, and contextual risk signals. The ZTNA model replaces traditional VPN with per-application access control. Users authenticate to the IdP with MFA, which evaluates risk signals including device compliance (MDM/EDR status), geographic location, IP reputation, and time-of-day patterns. High-risk sessions trigger step-up authentication or are blocked entirely. Legacy VPN is retained only for specific legacy applications with restricted subnet access. All sessions are logged with correlation IDs for forensic traceability.

Connection Time p95
< 3 s
MFA Method
FIDO2 / TOTP / Push
Risk Score Latency
< 500 ms
Step-up Accuracy
> 98%
App Segmentation
Per-app micro-tunnel
Session Logging
100% with corr. ID
Risk SignalSourcePolicy Action
Device complianceMDM/EDR APINon-compliant → quarantine or step-up
Geographic locationIP geolocationUnexpected country → step-up or block
IP reputationThreat intel feedKnown bad IP → block immediately
Time-of-dayPolicy engineOff-hours access → step-up required
Velocity anomalyIdP analyticsImpossible travel → block + alert

Scenario 6: Privileged Access Management — PAM + TACACS+

PAM TACACS+ Admin Control
Figure 3.6: Privileged Access Management — Admin users authenticate through MFA/PAM vault to jump server; TACACS+ enforces command-level authorization with full session recording

Privileged access to network devices and servers requires the highest level of accountability. All administrative sessions are brokered through a PAM jump server, which enforces MFA, credential checkout with time-limited TTL, and full session recording. TACACS+ provides command-level authorization based on the admin's role, denying unauthorized commands and logging every permitted command with user identity and timestamp. Break-glass emergency procedures are documented and audited, requiring post-incident review. Shared admin accounts are prohibited; every admin uses a unique identity.

Session Recording
100% coverage
Credential TTL
1–4 hours
Command Log
100% completeness
Break-Glass Review
Within 24 hours
Shared Accounts
Zero tolerance
MFA Required
Always (no bypass)
Admin RolePermitted CommandsDenied CommandsApproval Required
Network Operatorshow, ping, tracerouteconfig, reload, eraseNo
Network Engineershow, config interface/VLANerase, reload, global routing changesChange ticket
Network AdminAll except erase/reloaderase startup-config, reloadChange ticket
Break-GlassAll commandsNone (emergency)Post-incident review

Scenario 7: Multi-Site Identity Federation and Survivability

Multi-Site Identity Federation
Figure 3.7: Multi-Site Federation — Central IdP/AD with identity replication to HQ and branch sites; local RADIUS cache enables survivability during WAN outage

Organizations with multiple sites require a federated identity architecture that provides both centralized policy control and local survivability. The central IdP and AD serve as the authoritative identity source, with identity data replicated to local domain controllers at each site. Each site maintains a local RADIUS/TACACS+ server that caches policy decisions and can authenticate users independently during WAN outages. Policy synchronization ensures that changes made centrally propagate to all sites within a defined SLA. The architecture supports 8–30 sites with consistent policy enforcement regardless of WAN availability.

AD Replication Lag
< 15 min
WAN Failover
< 30 s
Policy Sync SLA
< 5 min
Local Auth Cache
24–48 hours
Site Count
8–30 sites
WAN Redundancy
MPLS + SD-WAN
ConditionAuthentication PathPolicy SourceLimitations
WAN availableLocal RADIUS → Central AD/IdPCentral policy engineNone
WAN degradedLocal RADIUS → Local DCCached policy (last sync)New policy changes not applied until WAN restored
WAN downLocal RADIUS → Local DC cacheCached policyNo new user provisioning; no cert revocation updates
Complete site isolationLocal fallback VLANStatic fallback rulesRestricted access only; alert generated

Scenario 8: SIEM-Integrated Identity Audit and Alerting

SIEM Identity Audit SOC
Figure 3.8: SIEM Identity Audit — SOC analysts monitor authentication event timeline, failed login heatmap, VLAN assignment analytics, and privileged access alerts from centralized SIEM platform

A comprehensive identity audit capability requires all authentication and authorization events to flow into a centralized SIEM with consistent log schemas, correlation IDs, and NTP-synchronized timestamps. The SIEM provides real-time dashboards for authentication event timelines, failed login heatmaps, VLAN assignment analytics, and privileged access alerts. SOAR playbooks automate incident response for high-confidence detections such as impossible travel, brute-force attacks, and unauthorized command execution. Log retention of 180–365 days supports forensic investigations and compliance reporting.

Log Ingest EPS
Headroom ≥ 30%
Retention Period
180–365 days
Alert Latency
< 5 min
NTP Offset
< 100 ms
Log Format
CEF / JSON
Correlation ID
100% coverage
Log SourceKey FieldsAlert TriggerSOAR Action
RADIUSUser, device, VLAN, result, timestampAuth failure rate > thresholdBlock MAC; notify admin
TACACS+User, device, command, result, timestampUnauthorized command attemptTerminate session; open incident
NACDevice, profile, VLAN, CoA, timestampUnknown device in sensitive zoneQuarantine; alert SOC
PAMUser, target, session ID, commands, recordingBreak-glass usageNotify CISO; schedule review
IdPUser, risk score, MFA result, app, timestampImpossible travel detectedBlock session; force password reset

3.1 Scenario Selection Guide

The following matrix provides a structured framework for selecting the appropriate scenario combination based on organization size, site count, device diversity, and compliance requirements. Most enterprise deployments will implement multiple scenarios simultaneously, with the combination determined by the specific risk profile and operational environment.

Organization ProfilePrimary ScenariosOptional ScenariosKey Drivers
Small enterprise (< 500 users, 1–3 sites)1 (Wired), 2 (Wi-Fi), 4 (Guest)5 (Remote), 8 (SIEM)Simplicity; low OpEx; standard compliance
Mid-size enterprise (500–2000 users, 3–10 sites)1, 2, 3 (IoT), 4, 5, 6 (PAM)7 (Multi-site), 8IoT growth; remote work; audit requirements
Large enterprise (2000–10000 users, 10–30 sites)All 8 scenariosAdvanced SOAR integrationZero Trust journey; regulatory compliance; SOC maturity
High-security / regulated (finance, healthcare, government)All 8 scenarios + PAM deep integrationHardware security keys; air-gapped segmentsStrict audit; SoD; privileged access controls