BUILD-002 · Zero-trust PoC
Grant access.Then takeit away.
From a machine certificate to the application: Cisco ISE, 802.1X and Secure Firewall in a verified chain of access decisions.
Verified on 25 September 2026 · Configlane
Same client. Same application.
01 · Authorized
HTTP 200
EAP-TLS · VLAN 11 · SGT 20
02 · Authorization withdrawn
Access denied
Policy change + CoA
03 · Access restored
HTTP 200
Rule enabled · reauthorized
The question
What can an authenticated device actually reach?
A device presents its machine certificate, receives a defined role and reaches the application allowed for that role. When its authorization changes, that access must disappear. We built this chain and verified it with real application traffic.
The client authorized through EAP-TLS receives a successful HTTPS response. A registered IoT device gains network access in a separate segment but is blocked from the same application. After a targeted policy change and Change of Authorization, the previously authorized client loses access too. Once permission is restored, its HTTPS request succeeds again.
01 / Architecture
Every decision has a place.
ISE decides on network admission. The Catalyst enforces that decision at the port. The firewall restricts routed traffic to the application.
AD / Enterprise-CA
Identity and certificates
Cisco ISE
RADIUS / CoA
Cisco FMC
Policy management
ISE → Catalyst: admission and role. FMC → FTD: firewall policy.
Data path to the application
- 01 / Identity
Endpoints
EAP-TLS / MAB
- 02 / Admission
Catalyst
VLAN 11 / 12 · SGT 20 / 30
- 03 / Segmentation
Secure Firewall
IP-based rules
- 04 / Access
Application
HTTPS
EAP-TLS · VLAN 11 / SGT 20
Authorized client → HTTPS allowed
MAB · VLAN 12 / SGT 30
Registered IoT → HTTPS denied
- 01
Verify identity
EAP-TLS, trusted certificates and a machine identity that can be resolved.
- 02
Determine authorization
ISE evaluates the authentication method and group, then assigns a VLAN and Security Group Tag.
- 03
Enforce access
The access port controls admission. FTD allows or blocks application traffic.
02 / EAP-TLS
Certificate meets directory identity.
- Exact EAP server name validation
- AD group: Domain Computers
- VLAN 11 / SGT 20
- Default: DenyAccess
The Linux client uses a machine certificate issued by the enterprise CA. Its supplicant validates the trusted CA and the exact name of the ISE EAP server. The private client key remains on the endpoint, protected by file mode 0600.
ISE extracts the identity from the certificate. Authorization resolves it to the pre-provisioned AD computer account and its Domain Computers group. The Linux client itself is not domain-joined for this particular test. Certificate validation and group-based authorization are separate steps [1].
The matching rule returns VLAN 11 and SGT 20. The Employee role names the authorized device segment here; the verified identity is a computer account. Only EAP-TLS is allowed for 802.1X. The observed handshake negotiated TLS 1.2.
Before authorization, the data port was blocked and the HTTPS request failed. After EAP-TLS, the Catalyst reported Authorized, including VLAN 11 and SGT 20. A new request through the client's data interface returned HTTP 200.
03 / MAB
Limited rights for IoT.
Network access granted. Application access denied.
The second endpoint uses MAC Authentication Bypass. ISE accepts an explicitly registered MAC address in a defined endpoint group and assigns VLAN 12 and SGT 30. Unknown devices do not receive a general permit.
A MAC address can be impersonated. MAB therefore does not provide cryptographic proof of identity [2]. The endpoint receives only the access intended for its role.
The IoT endpoint was successfully authorized at the Catalyst. Its HTTPS request to the protected application still timed out. At the same time, the matching FTD deny counter increased from 7 to 14. The same application was reachable from the EAP-TLS client.
04 / Change of Authorization
Change the permission. Verify the effect.
We disabled the matching authorization rule, used ISE to re-evaluate the session and then restored the original permission. Firewall rules remained unchanged throughout.
Selected verification step 1 / 3
Access granted
EAP-TLS identifies the client. The AD group condition matches and the authorization rule is enabled.
- New HTTPS request
- HTTP 200
- Catalyst session
- Authorized
- ISE decision
- VLAN 11 / SGT 20
Interactive view of the measured test sequence · no live connection
The CoA call triggered reauthentication of the selected session [3]. We tested new HTTPS requests after withdrawing authorization. Revocation latency and the behavior of existing long-lived connections were not measured.
05 / Acceptance
The access matrix.
Session state and application outcome were evaluated together. Measurements follow the actual path from the client to the service.
| State | Network access / role | HTTPS outcome | Evidence |
|---|---|---|---|
| Before EAP-TLS | Unauthorized | Denied | Request failed |
| After EAP-TLS + AD | VLAN 11 / SGT 20 | HTTP 200 | Authorized + app response |
| Registered IoT / MAB | VLAN 12 / SGT 30 | Denied | Timeout + FTD deny 7 → 14 |
| Policy withdrawal + CoA | Unauthorized | Denied | ISE 15039 + timeout |
| Permission restored | VLAN 11 / SGT 20 | HTTP 200 | Reauthorized |
| After recovery | EAP-TLS / MAB retained | Depends on role | HTTP 200 / FTD deny 0 → 7 |
The supplicant has a separate management connection. Application tests used its NAC data interface. Routes, forwarding, next hops and return paths were checked. Access ACLs block direct Employee-to-IoT routing on the switch; the internal FTD path does not use NAT.
SGT / TrustSec
Assignment at the access layer. A precise scope of proof.
Verified: SGT assignment
ISE returns SGT 20 or SGT 30. The Catalyst displays both values on their respective sessions. This proves the mapping from authenticated identity to security group at the access layer.
Enforced: IP-based firewall rules
FTD makes decisions based on the client networks in this PoC. FMC integration through pxGrid, SGT-based firewall rules and SGACL enforcement were not verified.
A complete TrustSec verification would also test how the group mapping is propagated and used at each enforcement point.
06 / Recovery
Saved. Restored. Verified again.
- EAP-TLS: HTTP 200
- IoT: FTD deny 0 → 7
- VLAN / SGT retained
After acceptance, we saved the complete state and started the deployment again from it. EAP-TLS, MAB, VLAN/SGT assignment and allowed and denied HTTPS requests were checked again. The required certificates and private keys were present.
The EAP-TLS client reached the application again. IoT access remained blocked and generated fresh hits on the FTD rule. No subsequent configuration changes were required.
The verified stack
Software versions in this PoC.
| Component | Role | Version |
|---|---|---|
| Cisco ISE | EAP-TLS, AD, VLAN/SGT, CoA | 3.5.0.527 Patch 4 |
| Cisco FMC | Access-control policy management | 10.0.1 Build 1 |
| Cisco FTD | Application access enforcement | 10.0.0 Build 140 |
| Virtual Catalyst 9000 | Authenticator / access | IOS XE 17.18.2 |
| Windows Server | AD, DNS, enterprise CA | Server 2022 |
| Linux / wpa_supplicant | Wired 802.1X | Ubuntu 24.04.4 |
These are the versions tested. Platform selection and software approval for production are separate, project-specific decisions.
07 / Scope & next steps
A sound foundation for the next step.
The PoC connects identity, role selection, allowed and blocked data paths, and withdrawal of permission. Each step can be observed individually and tested as part of the complete chain.
The documented 802.1X result applies to the wired Linux supplicant. Windows 802.1X, production throughput and scale are outside this result. Automated risk-based quarantine was not configured.
- Certificate lifecycle, including CRL / OCSP
- Failure behavior and high availability
- Rollout to the intended endpoint platforms
- Posture and SGT-based enforcement
Sources and context
Results come from our own acceptance checks on 25 September 2026. The Cisco sources explain the underlying mechanisms.
- [1]Configure EAP-TLS Authentication with ISE
Cisco · Published / updated: 2023-07-13 · Checked on 25 September 2026
- [2]Trust Analytics and Anti-Spoofing Protection
Cisco Blogs · Published / updated: 2021-07-20 · Checked on 25 September 2026
- [3]Using Change of Authorization REST APIs
Cisco DevNet · Checked on 25 September 2026