Before anything — the doorman, the ID-checker and the ID card
Imagine a fancy office building. The doorman at the gate does not personally know everyone — he just relays your ID to the security desk at the back, which holds the real records. The desk says "yes, let her in, give her the 3rd-floor badge", and only then does the doorman open the gate. That is 802.1X in one sentence.
Meraki access control has two halves. Authentication answers "who are you?" using 802.1X talking to a RADIUS server. Authorization answers "what may you touch?" using a returned VLAN, group policy, or — the modern way — a Security Group Tag enforced by Adaptive Policy.
Architecturally, Meraki separates the policy decision point (RADIUS / Cisco ISE) from the policy enforcement point (MR access point, MS switch, MX). 802.1X / RADIUS carry identity inbound; the Access-Accept carries authorization outbound (VLAN, Filter-Id group policy, or SGT). Adaptive Policy decouples policy from topology entirely by tagging traffic at ingress and enforcing the group-to-group matrix at egress, which is what lets it scale across many sites without per-VLAN ACL sprawl.
Three roles repeat through every demo below — learn them once and the rest is easy:
The client — laptop, phone, camera. It runs the 802.1X "supplicant" software and presents credentials (password, certificate, or just its MAC for MAB).
The Meraki MR / MS / MX. It is the doorman — it relays EAP between the client and the server but makes no decision itself. Also called the NAS (Network Access Server).
The authentication server — Windows NPS, Cisco ISE, or a cloud RADIUS. It holds the identity store and returns Access-Accept (with VLAN/group/SGT) or Access-Reject.
The authorization result: a VLAN, a group policy, or an SGT. This is the badge that decides which floors you can reach once you are inside.
① 802.1X & RADIUS — the front door
Sneha, an L1 at a Bengaluru SaaS firm, is told "make the corporate Wi-Fi ask for AD logins, not a shared password." That single sentence is a WPA2-Enterprise SSID pointed at RADIUS. Let us build it.
On the dashboard you go to Wireless > Configure > Access control, pick the SSID, and under Security choose Enterprise with my RADIUS server (this is 802.1X / WPA2-Enterprise). Then add the RADIUS server's IP, port 1812, and the shared secret.
▶ Watch an 802.1X / WPA2-Enterprise handshake
Click Play. Each stage lights up as Sneha's laptop authenticates to the corporate SSID.
sneha@corp.local
10.1.10.20:1812
Wireless > Configure > Access control > SSID "Corp-Secure" Association requirements : WPA2-Enterprise with my RADIUS server RADIUS servers : 10.1.10.20 port 1812 secret ******** RADIUS accounting (opt) : 10.1.10.20 port 1813 Client VLAN tagging : RADIUS assigned VLAN
Access-Request : User-Name=sneha@corp.local Called-Station-Id=AP-3F
Access-Accept : Tunnel-Type=VLAN Tunnel-Medium-Type=802
Tunnel-Private-Group-Id=30
Client status : 802.1X authenticated, VLAN 30, signal -54 dBm
On wired MS switches the idea is identical: Switch > Configure > Access policies, create an 802.1X policy, point it at the same RADIUS server, then apply that policy to the access ports. One important wired detail: when an MS access policy uses a RADIUS server, the switch authenticates using PAP, so your server must accept PAP for those requests.
Pause & predict: a laptop with perfect AD credentials fails to join, and the RADIUS server logs show zero Access-Requests. Before you read on — where is the break?
On a Meraki MR SSID you set Security to WPA2-Enterprise with "my RADIUS server". A laptop with valid AD credentials still fails to associate, and the RADIUS server logs no Access-Request at all. Most likely cause?
② Dynamic VLAN + group policy + Cisco ISE
Rahul, an L2 at a Pune services firm, wants finance laptops on VLAN 30 and guests on VLAN 80 — on the same SSID. He does not want two SSIDs. The answer is RADIUS-assigned VLAN: the Access-Accept itself tells the AP which VLAN to drop the client into.
Three RADIUS attributes do this, and you need all three in the Access-Accept:
Where does Cisco ISE fit? RADIUS alone is a yes/no oracle. ISE is the brains on top: it can choose the VLAN, group policy or SGT dynamically based on who the user is, what device they are on, the device's posture, and the device profile. A managed laptop with healthy posture gets VLAN 30; the same user on a personal phone gets a guest VLAN.
You configure dynamic VLAN on an MS switch access policy. Your RADIUS server returns Tunnel-Private-Group-ID = "CORP" (the VLAN name). Clients authenticate fine but always land on the default VLAN. Why?
30) or enable VLAN Profiles (Network-wide > Configure > VLAN profiles) so the name resolves. A shared-secret error would block auth entirely, not just misplace the VLAN.For devices that cannot run a supplicant at all — printers, badge readers, IP cameras — you use MAB. The port still authenticates, but the "credential" is just the device MAC. It is weaker (MACs are trivially spoofed) so always pair MAB with ISE profiling and a tight authorization.
Use 802.1X with MAB fallback. Capable devices get strong certificate or credential auth; printers and phones that can't do 802.1X fall back to MAB without you leaving the port wide open. MAB-only everywhere is weak; 802.1X-only locks out the half of your fleet that has no supplicant.
Pause & predict: finance laptops should hit VLAN 30, but they all land on the default VLAN even though auth succeeds. The Accept contains only Tunnel-Private-Group-ID=30. What is missing?
Tunnel-Type=VLAN(13) + Tunnel-Medium-Type=802(6) + Tunnel-Private-Group-ID=30. With only the group-ID present, Meraki ignores the assignment and uses the SSID/port default VLAN.An IoT camera can't run an 802.1X supplicant. You need it online without leaving the port open. Correct Meraki approach?
③ Adaptive Policy — tag the traffic, not the subnet
Priya, an architect at a multi-site retailer, is drowning in inter-VLAN ACLs — 40+ rules per site, all breaking whenever someone re-IPs a subnet. Adaptive Policy is the fix: stop writing rules about subnets, start writing rules about groups.
Here is the core idea. Every endpoint is classified into an Adaptive Policy Group, and that group has a number called a Security Group Tag (SGT). As traffic enters the network, the Meraki device stamps that SGT into the frame's CMD header. As traffic leaves toward its destination, the destination device looks up a simple matrix — "is Group A allowed to talk to Group B?" — and permits or drops it.
Think of it like coloured wristbands at a festival. Instead of guards memorising which gate each person came from, everyone wears a colour. A red band can enter the red zone, not the green zone — no matter which gate they used to get in. The colour is the SGT.
Two default groups exist out of the box: Infrastructure and Unknown. SGT values are unique numbers from 3 to 65519 (auto-allocated if you don't pick one), and once assigned a value can't be changed. Supported platforms include modern MS switches (MS130 / MS150 / MS390 / C9K-M), MR/CW Wi-Fi 5/6/7 APs, and MX/Z3+ on recent firmware — the catch is that every device in the path must support and carry the tag.
The architectural win is decoupling: policy is expressed group-to-group and enforced at the destination (egress), so it is IP- and VLAN-agnostic and globally scalable. One matrix replaces many per-site ACLs, and a re-IP or re-VLAN event does not touch policy. The classification source is typically Cisco ISE, which can push the SGT dynamically by user/device/posture and re-tag via Change of Authorization (CoA) without disrupting the client. The price: hardware/firmware support everywhere and a disciplined monitor-first rollout.
▶ Watch a Security Group Tag travel
A finance laptop (SGT 30) tries to reach an HR server (SGT 40). The matrix says DENY.
In Meraki Adaptive Policy, what is a Security Group Tag (SGT), and where is the policy actually enforced?
④ Troubleshoot — auth, VLANs, SGTs & a CVE you must patch
You've configured it. Something's broken. Here's the 4-step ladder that resolves most Meraki access-control tickets in under 5 minutes.
On ISE/NPS, is there an Access-Request? No request = AP not a NAS client / UDP 1812 blocked. Reject = credential / EAP / cert issue.
All three VLAN attributes present? Numeric ID (not a name)? Wrong VLAN = missing attribute or name-vs-ID trap.
Dashboard > Clients > the device. Shows 802.1X status, assigned VLAN, group policy and SGT. Compare to what you expected.
If an allowed flow drops, a transit device is stripping the tag — an unsupported model or old firmware sees Unknown and the matrix denies it.
Symptom: client never connects, RADIUS shows nothing. Cause: AP isn't a registered NAS client or UDP 1812 is filtered.
Symptom: auth succeeds but everyone lands on the wrong VLAN. Cause: a VLAN attribute is missing, or you returned the VLAN name without enabling VLAN Profiles.
Symptom: Adaptive Policy drops an allowed flow on some paths only. Cause: a transit switch/AP doesn't support Adaptive Policy or is on old firmware (pre-MS17 / MR27), so it strips the SGT and the destination sees Unknown.
Access control is not just config — it is also keeping the boxes patched. In 2025 Cisco disclosed CVE-2025-20271 and related advisories affecting the AnyConnect VPN server on Meraki MX and Z-series gateways (unauthenticated denial-of-service / session issues). Separately, CVE-2025-20352 (a Cisco IOS-affecting SNMP flaw) was reported exploited in the wild. Lesson: subscribe to Cisco Security Advisories and keep MX/MR/MS firmware current — an unpatched edge undermines every access-control rule behind it.
Which RADIUS attributes must the Access-Accept contain for Meraki dynamic VLAN assignment to work?
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from Meraki docs + community Q&A. For complex prod issues, paste your ISE live-log line + the client details page into chat.techclick.in.
📝 Wrap-up — five more
You've already answered 5 inline. Five left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 Lock it in — explain it in your own words
In two or three lines, write how you'd explain to a junior the difference between authentication (802.1X / RADIUS) and authorization (VLAN / SGT). Writing it from memory is what moves it to long-term recall.
Teach a friend: message one teammate the single sentence — "The doorman (AP) never decides; the desk (RADIUS/ISE) does, and hands back a badge (VLAN or SGT)." If they get it, you've got it.
⏰ Remember this in 7 days
Want a 3-question spaced-recall nudge on Meraki access control in a week? Drop your email — we'll send one short quiz to cement it.
📖 Glossary
- 802.1X
- IEEE port-based Network Access Control — the standard behind WPA2/WPA3-Enterprise and wired port authentication.
- RADIUS
- Remote Authentication Dial-In User Service — the AAA protocol (UDP 1812 auth, 1813 accounting) the AP/switch queries.
- WPA2/WPA3-Enterprise
- Wi-Fi security in Enterprise mode — per-user authentication via 802.1X/EAP instead of one shared key.
- Cisco ISE
- Identity Services Engine — the policy server that authenticates and returns rich authorization (VLAN, group policy, SGT).
- MAB
- MAC Authentication Bypass — admits supplicant-less devices using their MAC as the RADIUS identity; weaker, pair with profiling.
- SGT
- Security Group Tag — a number (3–65519) in the CMD header naming a source's group, independent of IP/VLAN.
- Adaptive Policy
- Meraki's group-to-group policy framework enforced at egress, replacing per-subnet ACL sprawl.
- CoA
- Change of Authorization — RADIUS lets ISE re-authorize a live session (e.g. re-tag the SGT) without disconnecting the user.
📚 Sources
- Cisco Meraki Documentation — Access Control (MR) & Configuring RADIUS Authentication with WPA2-Enterprise. documentation.meraki.com
- Cisco Meraki Documentation — MS Switch Access Policies (802.1X) & MX Access Policies (802.1X). documentation.meraki.com
- Cisco Meraki Documentation — Adaptive Policy Overview / Configuration Guide & Adaptive Policy and Cisco ISE (SGT range 3–65519, default Infrastructure/Unknown). documentation.meraki.com
- Cisco Meraki Documentation — MAC Authentication Bypass (MAB) and iPSK & VLAN Profiles. documentation.meraki.com
- The Meraki Community — 802.1X w/ Dynamic VLAN Assignment & Does Meraki accept Tunnel-Private-Group-Id as a VLAN name? community.meraki.com
- Cisco Security Advisories — CVE-2025-20271 (Meraki MX/Z AnyConnect VPN DoS) & CVE-2025-20352 (IOS SNMP, exploited in the wild). sec.cloudapps.cisco.com
- Cisco Learning Network — 500-220 ECMS Exam Topics (Engineering Cisco Meraki Solutions) & Cisco Live BRKSEC-2100: ISE Your Meraki Network with Group-Based Adaptive Policy (2025).
What's next?
You can now get the right people onto the network with the right badge. Next we go deeper into the wired fabric — how Meraki MS switches stack, route at Layer 3, and enforce ACLs and QoS so all that tagged traffic actually moves fast and clean.