How to Implement Post-Admission NAC for Continuous Trust Monitoring

Welcome to the Purple Enterprise Architecture Briefing. I'm your host, and today we're tackling a critical shift in network security: moving from static authentication to Continuous Trust Monitoring using Post-Admission NAC. Joining me is our Senior Solutions Architect. Thanks for being here. Pleasure to be here. This is a topic that's coming up in almost every enterprise design discussion right now. Let's set the context. For years, we've relied on 802.1X and captive portals to secure the edge. Why is that no longer enough for environments like large retail chains or hospitality venues? It comes down to the trust model. Traditional NAC — what we call Pre-Admission NAC — is like a bouncer at a club. They check your ID at the door, and if you're on the list, you're in. But once you're inside, the bouncer isn't watching what you do. In a network context, a device might authenticate perfectly cleanly. But what if, ten minutes later, that device downloads a malicious payload and starts scanning the internal point-of-sale subnet? Pre-Admission NAC has already done its job and stepped away. Post-Admission NAC is the security guard walking the floor. It continuously monitors the session and can intervene dynamically. So we're talking about real-time behavioural analysis. How does that actually work under the hood? Exactly. It requires two main components: telemetry ingestion and a dynamic policy engine. First, we need visibility. The Network Access Devices — the wireless LAN controllers, the switches — need to stream telemetry back to the NAC engine. We're talking NetFlow, IPFIX, RADIUS accounting data. The NAC engine uses this to establish a behavioural baseline. What does normal traffic look like for a guest device at a hotel? What does normal look like for a medical infusion pump? Once you have that baseline, deviations become detectable. And when an anomaly is detected? That's where the enforcement comes in, typically using RADIUS Change of Authorization, or CoA. If a guest device suddenly starts generating massive volumes of SMB traffic — the kind of traffic you'd see from a ransomware infection — the NAC engine detects the anomaly and fires a CoA request to the wireless controller. The controller can then bounce the client, drop them into a quarantine VLAN, or apply a restrictive access control list — all mid-session, without any manual intervention from your network team. That sounds powerful, but also potentially disruptive if not implemented correctly. What are the common pitfalls you see in the field? The biggest pitfall is turning on active enforcement too quickly. You have to follow a phased approach. Phase one is always Monitor Only. You need to let the system ingest telemetry and build accurate baselines. If you jump straight to enforcement, you will generate false positives, and in a hospitality or public venue setting, disconnecting legitimate users is an operational nightmare. I always tell clients: Monitor, Measure, Mitigate. That's the framework. The Monitor, Measure, Mitigate framework. Let's unpack that. Sure. Monitor means deploying in passive mode — all telemetry flowing in, no enforcement actions. Measure means reviewing the data, adjusting thresholds, and stress-testing your policies against known-good traffic. Mitigate is when you enable active enforcement, starting with a graduated response — perhaps a restrictive ACL before a full disconnect — and then escalating from there. Skipping directly to Mitigate is the single most common mistake I see. What's the second major pitfall? CoA failures. Change of Authorization relies on UDP port 3799. Often, firewalls between the central NAC engine and the branch routers block this traffic, or the RADIUS shared secrets are mismatched. If CoA fails, you don't have Post-Admission NAC; you just have a very expensive alerting system. Your logs will show the anomaly, but nothing will happen on the network. Always validate CoA in a lab environment before production rollout. Let's talk about IoT. How does this apply to environments heavy on headless devices, like healthcare? It's arguably even more critical there. Many medical IoT devices can't support 802.1X, so they rely on MAC Authentication Bypass, or MAB. MAB is incredibly vulnerable to MAC spoofing — an attacker can clone the MAC address of a trusted device and gain access to the clinical network. Post-Admission NAC mitigates this by profiling the device's behaviour. An infusion pump has a very predictable traffic pattern — it communicates with a specific internal server on a specific port, at regular intervals. If a device authenticates with the pump's MAC address but starts running port scans or communicating with external IP addresses, the continuous monitoring catches it instantly and quarantines the switch port. That's a compelling use case. What about large public venues — stadiums, conference centres? High-density environments are a perfect fit for this approach, but they come with their own challenges. You're dealing with thousands of concurrent sessions, all generating telemetry. Your NAC policy engine and your logging infrastructure need to be scaled to handle that ingest rate. We typically recommend a distributed architecture — local telemetry collectors at each venue feeding into a centralised policy engine — rather than trying to backhaul all raw telemetry across a WAN link. The Purple WiFi Analytics platform integrates well here, providing session-level context that enriches the NAC engine's decision-making. Let's do a rapid-fire Q&A based on common client questions. First: Does Post-Admission NAC replace my firewall? No. It complements it. Firewalls protect the perimeter and the boundaries between network segments. NAC protects the access edge and prevents lateral movement within the same segment. You need both. Second: Can this integrate with our existing SIEM? Absolutely, and it should. The NAC engine should be sending events to your SIEM for correlation. A quarantine event on the network combined with a corresponding alert in your endpoint detection system is a much stronger signal than either in isolation. Third: What's the immediate ROI for a CTO? Drastically reduced Mean Time to Respond. You're automating the quarantine of compromised devices from hours — or days — down to milliseconds. That protects your brand, reduces the operational burden on your network team, and provides the audit trail your compliance team needs for PCI DSS and GDPR. Excellent. To wrap up: the key takeaways from today's briefing. Post-Admission NAC shifts your security model from a static entry check to continuous, dynamic trust evaluation. The enforcement mechanism is RADIUS Change of Authorisation — get that working reliably before anything else. Always deploy in phases: Monitor, Measure, Mitigate. Behavioural baselining is your foundation — invest the time to get it right. And finally, this approach aligns directly with Zero Trust architecture principles, which is where every enterprise network is heading. Thanks for the insights, and thank you all for listening to the Purple Enterprise Architecture Briefing. If you'd like to explore how Purple's platform can support your Post-Admission NAC deployment, visit purple dot ai to speak with our solutions team.