Cisco Meraki Access Manager: Configuration Guide

Cisco Meraki Access Manager brings cloud-hosted RADIUS and network access control into the Meraki dashboard, so you can run 802.1X, MAB and iPSK across switches and access points without standing up an on-prem RADIUS server like ISE or NPS. This guide walks the full build end to end: the core policy objects, wired and wireless enforcement, a practical VPN pattern, and the day-two monitoring and troubleshooting workflow. Architecture diagrams, decision flows and dashboard mockups are included for every major step.

1. Overview

Cisco Access Manager is a cloud RADIUS/NAC service built into the Meraki dashboard. It authenticates and authorizes wired and wireless endpoints on Meraki-managed switches and APs without an on-prem RADIUS server such as ISE or NPS. It went GA on 2025-11-10 and is configured under Access Manager in the left-hand menu.

The UI mockups in this guide are recreations based on Meraki documentation as of the date above. Field labels can shift between dashboard releases, so confirm against your own dashboard before a customer change window.

How it works

1. The endpoint connects to an MS switch port or MR/CW SSID that is set to use Access Manager.

2. The switch or AP forwards the RADIUS request to the Meraki cloud over RadSec, carried inside the existing dashboard management tunnel. No RADIUS server IPs or shared secrets are configured.

3. Access Manager authenticates the endpoint (EAP-TLS, EAP-TTLS/PAP, MAB or iPSK). For identity lookups it uses a locally synced copy of Microsoft Entra ID.

4. Access Rules are evaluated top to bottom, first match wins. The matching rule returns Accept, Reject, or Accept with overrides (VLAN, voice domain, SGT, iPSK, group policy).

5. The switch or AP enforces the result. SGT enforcement depends on the device’s own licensing and hardware.

RadSec runs inside the dashboard tunnel, so there are no RADIUS IPs or shared secrets to configure; Entra lookups hit the synced copy, not a live API call.

Endpoints doing 802.1X must trust the server certificate eap.meraki.com, which Access Manager presents for every organization.

Scope at a glance

Licensing and prerequisites

• License: Cisco Access Manager Advantage, separate from MS/MR Advantage. Metered on peak concurrent active endpoint MACs per UTC day. SKUs include LIC-ACCSMGR-A-1Y/3Y/5Y (co-term) and subscription or EA options.

• Trial: 90 days for co-term organizations, extendable by two 30-day extensions.

• Availability: All Meraki regions except Canada, mainland China, India regional clouds and FedRAMP. Not supported with per-device licensing (PDL).

• Adaptive Policy: SGT enforcement requires MS/MR Advanced (Advantage) device licensing.

• Wireless firmware: MR 30.7 or later. Cloud-configured Catalyst C9200/C9300/C9350/C9500H need IOS XE 17.18.1+ per the device table; check the live Devices table for your model.

• Optional: a private CA for EAP-TLS, an Entra ID tenant for user/group lookups, and a UEM (Systems Manager, Intune) to push supplicant profiles and certificates.

Recommended build order

1. Apply the license or start the trial.

2. Set the Default Rule (start with Allow Access in a lab; move to Deny Access for production).

3. Build Adaptive Policy groups and the policy matrix, if SGTs are in scope.

4. Create Clients and Client Groups for MAB and iPSK.

5. Upload the CA chain (EAP-TLS only).

6. Integrate Entra ID (group lookups and EAP-TTLS only).

7. Configure switch access policies and SSIDs.

8. Write Access Rules and test in the Session Log.

2. Core building blocks

Every use case in this guide is built from the same five objects. Set them up once at the organization level, then reference them from switch policies, SSIDs and rules.

Access Rules

Rules are evaluated top to bottom and the first match wins. Every condition in a rule’s What’s matched section must be true (logical AND); there is no OR, so build one rule per alternative. If nothing matches, the Default Rule applies. A failed authentication (bad certificate, wrong password) is always rejected, regardless of the Default Rule.

Condition sources:

• Network Access: SSID, EAP Protocol, Auth Method, Subject-SAN-DNS, Subject-SAN-RFC822

• Endpoints: Client group, Type, Manufacturer, Model, OS, Source (for example Discovered)

• Entra ID domain: Account Enabled, Group (Match Any)

• Endpoint certificate: issuer and subject attributes, for example Issuer Common name contains

Authorization (Access permission):

Ordering guidance from Meraki:

1. Put the most frequent scenarios first, and specific rules above general ones.

2. Put exceptions and block-lists above the rules they override.

3. Within a rule, put static conditions (Network Access, RADIUS) before dynamic ones (Entra group, client group, certificate attributes).

Default Rule

Policy changes apply immediately to ports and SSIDs with live clients. Start with an open Default Rule or lab ports, watch the Session Log, then tighten.

Adaptive Policy (SGT)

1. Groups: Access Manager > Policies > Adaptive Policy > Groups > + Add Group. Typical set: Employees, Guests, IOT, Cameras, VOIP, Printers, Infrastructure, Quarantined, Unknown.

2. Custom ACLs: + Add custom ACL with Name, IP Version and rules (Policy, Protocol, Src port, Dst port, Log).

3. Policies: the source-to-destination matrix. Cells default to Allow All and can be set to Allow, Deny, or a custom ACL.

4. Networks: select the networks and click Enable. The dashboard pushes the change to devices within a few minutes.

Clients and Client Groups

• Access Manager’s Clients list is separate from Network-wide > Clients and starts empty.

• Add one client with + Add Clients > Add a Client: MAC address, Description, optional iPSK (8 to 63 characters), Client Groups.

• Bulk import with Upload CSV. Template columns: MAC address, Endpoint device group (semicolon-separated; groups are auto-created), Description, IPSK.

• iPSK values can be reset but never viewed. There is no UI export; use the /nac/clients API.

Certificates

1. Access Manager > Configure > Certificates > Upload CA certificate.

2. Upload the full chain (root and intermediates) as one Base64 .cer or .crt file, certificates pasted one after another.

3. Set Identity to the certificate field that matches the Entra user. Meraki recommends Subject Alternative Name RFC822.

4. Set Status to Enabled and Trusted Anchor to Enabled on at least one certificate in the chain.

5. Optional: Use for Extended Local Authentication lets APs cache the chain for cloud-outage fallback.

6. Optional: upload a CRL (.pem) or set a CRL URL, including base and delta CRLs.

Entra ID integration

In Azure (Entra admin center):

1. App registrations > New registration. Copy the Application (client) ID and Directory (tenant) ID.

2. Certificates & secrets > New client secret. Copy the value now; it is shown once. Record the expiry date.

3. API permissions: Microsoft Graph Application Group.Read.All, User.Read.All, Domain.Read.All (needed with two or more tenants) and Delegated User.Read. Click Grant admin consent.

4. If MFA Conditional Access applies to all users, exclude this app registration. EAP-TTLS/PAP cannot do MFA.

In the Meraki dashboard:

1. Organization > Monitor > Users > Configure > Integrate with Microsoft Entra ID.

2. Enter the tenant ID, client ID and secret value.

3. Leave Proactive Sync on for an automatic sync every ~6 hours (up to 150,000 users and 100,000 groups). Manual sync is under Sync.

4. Confirm the synced users and groups appear. All groups sync; there is no group filter.

Allow outbound HTTPS to login.microsoftonline.com. Rule lookups use the synced copy, so a new group membership can take up to one sync cycle to apply.

3. Wired security (MS and cloud-configured Catalyst)

One hybrid access policy (802.1X first, MAB on timeout) covers corporate laptops, phones, printers and IoT on the same port. Rules then sort each endpoint into the right VLAN or SGT.

Use cases

Step 1: Create the switch access policy

Path: Switching > Configure > Access Policies > + Add Policy

Open authentication mode and pre-auth group policy ACLs are not supported with Access Manager.

Step 2: Apply the policy to ports

1. Switching > Monitor > Switch Ports, filter and select the access ports.

2. Click Edit. Set Port status Enabled, Type Access, Access policy AM_Hybrid_MultiAuth.

3. Click Update.

The change is live on save. Pilot on a few ports with the Default Rule set to Allow Access before rolling to a floor.

Step 3: Prepare identities

• W1/W2: upload the CA chain (Section 2, Certificates). Push the EAP-TLS profile and certificates with a UEM. Set the profile to trust eap.meraki.com.

• W3/W4: add phones, printers and cameras to Client Groups by CSV, or rely on profiling (Type, Manufacturer) for phones.

• W2: complete the Entra ID integration.

Step 4: Write the rules

Path: Access Manager > Policies > Access Rules > + Add a rule. Suggested order:

VLAN numbers and domain names are examples. The VLAN must exist on the switch where the endpoint connects.

Certificate identity caveat: users and machines must share one identity attribute for Entra lookup. If users use SAN-RFC822 and machines use SAN-DNS, the Entra lookup works only for users. Keep machine rules on certificate attributes (rule 2) and user rules on Entra groups (rule 3).

Step 5: Verify

1. Connect a test laptop and phone. Open Access Manager > Monitor > Session Log.

2. Click the Status of each session to open Network Access Details. Confirm the matched rule, VLAN and SGT.

3. On the switch, check the port’s client details for the assigned VLAN and authentication state.

4. Wireless security (MR and CW)

Wireless uses one SSID per security type: an Enterprise SSID for corporate devices, an iPSK SSID for IoT, and an open MAB SSID for guests. Each SSID points to Access Manager instead of a RADIUS server list.

Use cases

Step 1: Create the Enterprise SSID (WL1, WL2)

Path: Wireless > Configure > Access Control, select the SSID from the dropdown.

Save. The SSID broadcasts within a few minutes.

Supplicant settings to push via UEM:

• EAP-TLS: client certificate from your CA, trust eap.meraki.com server cert.

• EAP-TTLS/PAP: inner method PAP, username is the Entra UPN, trust eap.meraki.com. Windows Hello for Business cannot use EAP-TTLS; use EAP-TLS for those devices.

No Entra call happens during the login itself; a user added to a group today may not match until the next sync.

Step 2: Create the iPSK SSID (WL3)

1. Same path. Security: Identity PSK with RADIUS, server Access Manager. Splash page: None.

2. Add each device under Access Manager > Configure > Clients with its MAC, a Client Group (for example Scanners) and an iPSK value, or import by CSV.

3. In the rule, choose the Identity PSK mode:

A client with the wrong passphrase can still show Success in the Session Log and re-authenticate every 5 to 10 seconds. Check the client’s association state if a device keeps reconnecting.

Step 3: Create the guest SSID (WL4)

1. Security: MAC-based access control (no encryption) with Access Manager.

2. Splash page: Click-through for an acceptable use page, or None.

3. Rule: SSID = guest, Auth Method = MAB, Allow restricted access with the guest VLAN and the Guests SGT.

Each active guest consumes an Access Manager license for the session. There is no automatic guest purge; filter Clients by the guest SSID and Last Seen, or call /nac/clients/bulkDelete.

Step 4: Write the wireless rules

Put the SSID condition first in each wireless rule so wired and wireless rules never cross-match.

Step 5: Verify

1. Join each SSID with a test device.

2. In the Session Log, confirm EAP protocol, matched rule, VLAN and SGT. For EAP-TLS, the details pane shows the client certificate attributes.

3. In Wireless > Monitor > Clients, confirm the client’s VLAN and group policy.

5. VPN security (MX Client VPN)

Access Manager does not authenticate VPN users today. It is not an option in the MX Cisco Secure Client (AnyConnect) authentication list, and its release notes through 2026-09-14 cover only switches and APs. The practical design is to secure VPN with the same Entra ID identity through SAML, so wired, wireless and remote users share one source of truth.

Options compared

Posture assessment (host scan) is not available on MX Secure Client, so device compliance must be enforced through Entra Conditional Access or the certificate requirement.

Use cases

Step 1: Enable Secure Client on the MX

Path: Security & SD-WAN > Configure > Client VPN > Cisco Secure Client Settings, set to Enabled.

Firmware: SAML needs MX 16.16+ or 17.5+. MX64/65 need 17.6+. Not supported on MX60, MX80, MX90 or Z1.

Step 2: Configure the Entra ID enterprise app (SAML)

1. In Entra, create a non-gallery enterprise application for the MX.

2. Set Identifier (Entity ID) to https://<vpn-hostname>/saml/sp/metadata/SAML.

3. Set Reply URL (ACS) to https://<vpn-hostname>/saml/sp/acs. Add :port if not 443.

4. Assign the VPN user group to the app.

5. Download the Federation Metadata XML.

6. Add a Conditional Access policy for this app: require MFA and, for V1, a compliant or hybrid-joined device.

Step 3: Finish on the MX

1. In Secure Client Settings, enter the SAML configuration Cisco Secure Client server URL (must start with https://).

2. Upload the metadata XML. The status changes from No File Found to SAML metadata File Uploaded.

3. Save, then connect with Secure Client and confirm the Entra sign-in and MFA prompt.

Step 4 (V2): RADIUS with group policy

1. Set Authentication type to RADIUS and add the server IP, port and shared secret (ASCII only). Timeout defaults to 3 seconds.

2. Enable Group policy with RADIUS filter-ID.

3. On the RADIUS server, return Filter-ID as a string that exactly matches the dashboard group policy name, for example Contractors-VPN.

4. Build that group policy under Network-wide > Configure > Group policies with Layer 3 firewall rules limiting destinations.

Step 5: Verify

• Network-wide > Monitor > Event Log, event type AnyConnect, for connects and auth failures.

• Network-wide > Monitor > Clients for active sessions.

• Entra sign-in logs for the SAML app to confirm MFA and Conditional Access results.

6. Monitoring and troubleshooting

The Session Log is the single place to see every authentication, which rule matched and what was returned. Start every investigation there.

Path: Access Manager > Monitor > Session Log. Click a session’s Status to open Network Access Details with all RADIUS, endpoint, Entra and certificate attributes.

Retention is 30 days in the dashboard and 31 days through /nac/sessions/history. There is no dashboard export. Active Sessions shows current license usage.

Common failures

Operational checks

• Default Rule matches the rollout phase (Allow in pilot, Deny or restricted in production)

• Entra client secret expiry is tracked

• CA and CRL renewals are tracked

• Critical Auth VLAN is set on switch policies

• Extended Local Authentication is enabled where Wi-Fi must survive a cloud outage

• License usage (90th percentile of daily peaks) is below purchased count

• Stale guest clients are purged on a schedule

7. SE and partner appendix

Position Access Manager for all-Meraki, Entra-first customers who want 802.1X, MAB and SGT segmentation without running RADIUS infrastructure. If a customer wants to keep ISE as the policy engine instead, see how to integrate Meraki with Cisco ISE. Position ISE when the customer needs posture, CoA, third-party NADs, VPN/device admin AAA, or identity sources beyond Entra.

Access Manager vs ISE

Proof of value plan

Durations are a suggested template, not a Meraki-published plan.

Design tips

• Plan the certificate identity attribute before issuing certificates. Users and machines must share one attribute for Entra lookup.

• Lead with SGTs rather than many VLANs. One user VLAN with SGT enforcement scales better and matches the Adaptive Policy matrix.

• Because there is no CoA, keep re-authentication timers reasonable (8 hours default) and document how to force re-auth after a policy change.

• Size licenses on peak concurrent endpoints, including guests, not on total known MACs.

• Use the REST API (/nac/clients, /nac/sessions/history, /nac/license/usage) for bulk client work, reporting and SIEM export, since the UI has no export.

• Firewall: allow the Meraki cloud ranges listed under Help > Firewall info and login.microsoftonline.com.

Limitations to disclose up front

• No RADIUS CoA, posture or UEM compliance checks

• Entra ID is the only IdP; Azure Government tenants are not supported

• EAP-TTLS/PAP cannot use MFA; the app registration must be excluded from MFA Conditional Access

• No PEAP documented; Windows Hello devices need EAP-TLS

• Not available in Canada, mainland China, India regional clouds or FedRAMP; not with PDL licensing

• Third-party switches and APs, and MX Client VPN, are out of scope

Sources

• Cisco Access Manager overview

• Cisco Access Manager Deployment Guide

• Architecture and Example Use Cases

• Licensing and Ordering Guide

• Release Notes

• EAP-TLS Certificate-Based Authentication with Entra ID Lookup

• MAB and iPSK for IoT Endpoints

• Integrating Microsoft Entra ID on the Organization Users page

• AnyConnect on the MX Appliance

• AnyConnect Authentication Methods