Cisco Meraki Dashboard Security Guide: Admins, API Keys and SAML

The Cisco Meraki Dashboard is the management plane for every switch, access point, security appliance and camera in a Meraki estate, so one stolen administrator session or leaked API key can reconfigure firewalls, open VPNs and capture packets across every site at once. Unlike on-premises network devices, there is no management VLAN to hide behind: the dashboard is a cloud service reached over the internet, and protection depends on administrator privileges, login security settings, SAML, API key handling and the change log. This guide covers how identity and access work in the dashboard, how to scope administrators, how API keys, OAuth integrations and webhooks behave, what to log and alert on, and a hardening baseline. It is for network and security engineers who run Meraki organisations, and for MSPs managing many of them. Settings and API fields are from the Meraki Dashboard API specification (v1.75.1) and Meraki documentation as checked in October 2026. For on-premises management plane practice, see the Network Device Management Plane Hardening Guide.

Key takeaways

• An API key is the admin who owns it. Meraki keys carry the owning identity's privileges in every organisation it can access, stay valid until revoked, and each identity can have up to two at a time. A full organisation admin's key is a full organisation admin.
• Login security is an organisation setting you must turn on. Two-factor authentication, lockout, idle timeout, password rules and login IP ranges are all switches under login security (enforceTwoFactorAuth, enforceAccountLockout, enforceIdleTimeout, enforceLoginIpRanges).
• Restrict API keys by source IP separately from the GUI. apiAuthentication.ipRestrictionsForKeys limits API key use to listed addresses or CIDR ranges without locking administrators out of the dashboard.
• SAML centralises people, not automation. SAML administrators cannot use the Dashboard API, and at least one non-SAML organisation admin must remain, so you still need a protected local account and a separate plan for automation identities.
• The change log and API request log are your audit trail. configurationChanges shows who changed what, and apiRequests shows each API call with admin ID, source IP and user agent, but API request history only goes back 31 days. Export both.

How identity and access work in Cisco Meraki Dashboard

Meraki organises access by organisation, then network, with network tags as a way to grant access to groups of networks. Each administrator is an identity (an email address) with an organisation access level and, optionally, per-network or per-tag privileges. An identity can belong to many organisations, which is how MSPs work, and its access can differ between them.

People authenticate either with a Meraki account (email, password and optional two-factor code by SMS or authenticator app) or through SAML single sign-on. The dashboard supports IdP-initiated SSO with entity ID https://dashboard.meraki.com and SP-initiated SSO with a per-organisation subdomain such as https://example.sso.meraki.com; both can run together. The IdP must send the username attribute https://dashboard.meraki.com/saml/attributes/username (an email is recommended, and it cannot match an existing admin's email) and the role attribute https://dashboard.meraki.com/saml/attributes/role, which must match a SAML role defined under Organization > Administrators. Only one role attribute is accepted. The IdP's certificate is pinned by its SHA-1 fingerprint (x509certSha1Fingerprint). For SAML fundamentals, see the SAML Security Guide.

Admin roles and privileged access

Full organisation administrators can add other administrators, change SAML, enable the API, change firewall and VPN configuration everywhere and generate API keys that inherit all of it. Keep that population small and make everyone else narrower.

• Prefer SAML roles over local admins: SAML lets you remove access centrally and apply your IdP's Conditional Access and MFA. Converting a local admin to SAML means deleting and re-adding the account.
• Keep alerting working: SAML administrators cannot receive Meraki emails and alerts, because no valid email address is guaranteed. Meraki recommends a non-SAML administrator to receive them; use a monitored shared mailbox identity with read-only rights.
• Watch MSP-style multi-organisation identities: an identity with access to many organisations is a high-value target, and its keys work in all of them. This is the classic trusted relationship path (MITRE ATT&CK T1199 Trusted Relationship).
• Review on a schedule: list administrators with GET /organizations/{organizationId}/admins and compare against HR and contracts monthly.

Integrations, API tokens and service accounts

Meraki API access is a non-human identity problem. There are three mechanisms, and the risk profile differs sharply.

• Create dedicated API identities: because keys inherit their owner's rights, create a non-person admin identity per integration (for example, a read-only identity for monitoring and a scoped identity for provisioning), generate the key there, and never use a full admin's personal key in automation.
• Prefer OAuth with the narrowest scopes: the dashboard:general scopes exclude identity and access management; grant dashboard:iam scopes only to tools that genuinely manage administrators or SAML.
• Restrict and rotate keys: enable ipRestrictionsForKeys so keys only work from automation hosts, rotate by generating a second key, switching the integration and revoking the first by its last four characters (/administered/identities/me/api/keys/{suffix}/revoke). Changes can take up to five minutes to propagate across organisations.
• Keep keys out of code: Meraki advises treating keys like passwords and storing them in environment variables (the Python library reads MERAKI_DASHBOARD_API_KEY) or a credential manager. Gitleaks includes a cisco-meraki-api-key rule that looks for 40-character hexadecimal values near the word Meraki. The xAI API Key Leak 2025 shows what happens when a scanner fires but nobody revokes: the key stayed valid for about two months. See the Git Secret Scanning Guide.
• Verify webhooks: check the shared secret on every inbound post and rotate it like any other secret; the receiver URL cannot be changed after creation, so create a new receiver to move it. See the Webhook Secrets Security Guide.
• Turn the API off where unused: the organisation setting api.enabled controls access to the Dashboard API for that organisation.

The broader pattern for SaaS tokens is in the SaaS API Token Security Guide.

Logging and detection

Pull the change log and API request log into your SIEM on a schedule, because the API log only reaches back 31 days. Map detections to MITRE ATT&CK: stolen admin sessions or keys (T1078.004 Cloud Accounts), new administrators or SAML role changes (T1098 Account Manipulation), firewall rule changes on MX appliances (T1686 Disable or Modify System Firewall), keys found in repositories (T1552.001 Credentials In Files), and forged or abused SAML assertions (T1606.002 SAML Tokens). The device-log side is covered in the Network Device Syslog and Configuration Change Detection Guide.

Metrics that show the dashboard is under control:

• Full organisation admins per organisation (target: four or fewer) and share of admins on SAML.
• API keys owned by personal admin identities rather than dedicated integration identities (target: zero).
• API calls from outside approved IP ranges per month (target: zero once restrictions are on).
• Configuration changes without a change record, from change log reconciliation.
• Days to revoke a leaked key after a scanner finding (target: same day).

Hardening baseline

1. Inventory. List organisations, administrators, SAML roles, API-enabled organisations and webhook receivers. Identify every key in use by asking integration owners and checking the API request log for user agents and source IPs.
2. Turn on login security. Set enforceTwoFactorAuth, enforceAccountLockout with a small accountLockoutAttempts, enforceIdleTimeout with a short idleTimeoutMinutes, a minimumPasswordLength of at least 14, and enforceDifferentPasswords. Use password expiration only if your policy requires it. Test with a pilot organisation first if you run many.
3. Restrict where admins and keys come from. Where administrators work from known egress addresses, set enforceLoginIpRanges with loginIpRanges (this covers the dashboard and the API); otherwise at least set ipRestrictionsForKeys. Enable enforceLockedIpSessions where supported. Keep the emergency admin's access path in mind before saving, or you can lock yourself out.
4. Move people to SAML. Configure the IdP with the username and role attributes, define SAML roles that mirror the persona table, enforce phishing-resistant MFA at the IdP, then delete local accounts except the emergency admin and an alert-receiving read-only identity. See the Phishing-Resistant MFA Guide.
5. Rebuild automation identities. Create a dedicated identity per integration with the minimum access, move integrations to OAuth where supported, store keys in a vault, and revoke personal keys.
6. Wire logging. Export the change log and API request log to the SIEM, configure syslog for device logs, and set alerts for configuration changes to a monitored destination.
7. Roll back safely. If SAML fails, use the emergency local admin; if an IP restriction blocks automation, adjust ranges from an allowed address. Record each change in the change log notes.

Framework mapping

Common misconfigurations

• Automation on a full admin's personal key: when that person leaves or is phished, every organisation they could reach is exposed. Use dedicated identities and OAuth.
• Two-factor not enforced: it is an organisation setting, not a default. Phished passwords are enough without it, as the Change Healthcare Breach 2024 showed for a remote access portal without MFA.
• No API key IP restriction: a key leaked from a laptop or repository works from anywhere. Restrict keys to automation egress addresses.
• SAML everywhere, alerts nowhere: SAML admins do not receive Meraki alerts, so a fully SAML organisation can silently stop receiving them. Keep a monitored non-SAML alert identity.
• Change log never exported: without a copy in the SIEM, malicious changes are found only when someone happens to look, and API request history ages out after 31 days.
• Broad MSP access: MSP identities with full access to many customer organisations multiply blast radius. Scope by network or tag and require the MSP to use SSO with MFA.

Practitioner checklist

• Enforce two-factor, lockout, idle timeout and a 14-character minimum password in every organisation.
• Limit full organisation admins to a few named people and one vaulted emergency local admin.
• Move administrators to SAML roles with phishing-resistant MFA at the IdP; keep a read-only non-SAML identity for alerts.
• Replace personal API keys with dedicated integration identities or OAuth apps with minimal scopes.
• Enable ipRestrictionsForKeys and, where practical, enforceLoginIpRanges.
• Enable the gitleaks cisco-meraki-api-key rule in repository scanning and revoke on detection the same day.
• Verify webhook shared secrets and rotate them.
• Export the change log and API request log to the SIEM at least daily and alert on admin, SAML and firewall changes.
• Review administrators, SAML roles and keys monthly.

Standards and references

• Cisco Meraki: Dashboard API OpenAPI Specification
• Cisco Meraki: Dashboard API Authorization
• Cisco Meraki: Configuring SAML Single Sign-on for Dashboard
• Cisco Meraki: Dashboard API Python Library
• Gitleaks: Default Rule Configuration
• MITRE ATT&CK: Cloud Accounts
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SaaS API Token Security Guide · API Key Management Guide · Network Device Management Plane Hardening Guide · Wi-Fi Security Guide