Skip to content

Classification: CONFIDENTIAL — Internal Use Only Document: access-control/admin-review-meraki-2026-04.md · v1.0 · 2026-05-07 · GPUS-IT

Meraki Administrator Access Review — April 2026

Scope

This review evaluates administrative access to the Cisco Meraki cloud-managed network platform — organization 395909 (Greenpeace USA) — encompassing all production admin accounts with access to the Meraki Dashboard and its underlying API. The review covers four current administrators across four network sites (WDC-Eye Street, MDEC, OAKEC, DC Apartments) plus the Major Gifts MDM-only network.

The review is the first formal admin-access audit conducted against the Meraki environment since its integration into GPUS-IT's documented infrastructure scope. It establishes a baseline for future quarterly reviews under the governance framework defined in access-review.md.

Methodology

Admin state was captured via authenticated Meraki Dashboard API on 2026-04-23 and 2026-04-27 by the IT Security Lead (Rajesh Chhetry):

  • GET /organizations/395909/admins — admin enumeration with lastActive timestamps
  • GET /organizations/395909/saml — SAML SSO configuration state
  • GET /organizations/395909/samlRoles — SAML role definitions
  • GET /organizations/395909/licenses/overview — license posture

API responses were saved to ~/meraki-discovery/ as point-in-time evidence. The 2026-04-27 snapshot is the authoritative reference for this review's findings.

Findings were reassessed on 2026-05-07 in light of operational context not previously documented; reassessment notes are recorded against individual findings below.

Current State (as of 2026-04-27)

Administrative Roster

Admin Email Org Access Last Active Auth Method Account Status
Rajesh Chhetry rajesh.chhetry@greenpeace.org full 2026-04-27 Email (local) Active
Tanu Garg tanu.garg@greenpeace.org full 2026-03-30 Email (local) Active
Mike Sedita msedita@greenpeace.org full 2025-11-25 Email (local) Active
Jack Sundius jack.sundius@greenpeace.org read-only 2026-03-04 Email (local) Active

Account count: 4 total — 3 full org access, 1 read-only.

Authentication Posture

  • SSO: Not configured. GET /organizations/395909/saml returned {"enabled": false}. No identity provider integration; all authentication is via local Meraki Dashboard email/password.
  • SAML roles: None defined. GET /organizations/395909/samlRoles returned [].
  • Multi-factor authentication: Per-admin 2FA enablement was not captured in the 2026-04-27 discovery — see Finding MERAKI-2026-04-011.

License Posture

Co-termination license, expires 2027-11-28, auto-renewal enabled. No license-driven access constraints relevant to this review.

Findings

MERAKI-2026-04-001 — Sedita stale administrative access

Severity at identification: High Status: CLOSED — access reviewed, retained with documented justification

Initial finding (2026-04-23): Mike Sedita holds full organizational admin access (orgAccess: full) with last active timestamp 2025-11-25 — approximately five months stale at identification, with no operational need previously documented. Initial assessment recommended access removal.

Reassessment (2026-05-07): Operational need re-evaluated in chat with the IT Security Lead. Active in-flight responsibility through Q2 2026 was confirmed, requiring retained full administrative access. The original 2026-04-23 assessment of "no operational need" was incomplete — the activity gap reflects task-driven rather than continuous access patterns, which the initial review process did not adequately characterize.

Resolution: Access retained. Sedita will be migrated to SAML via the apps-meraki-admins Okta group as part of the SSO cutover described in meraki-sso-runbook.md. Operational need to be re-evaluated at the end of Q2 (2026-06-30) and at next quarterly access review (2026-07).

Process learning: The initial finding was based on lastActive timestamp alone, without consultation on operational role. Future access reviews under this framework should pair API-level discovery with role consultation before recommending removal. Captured as finding MERAKI-2026-04-011 below.

MERAKI-2026-04-002 — Absence of platform-wide SSO

Severity: High Status: ACTIVE — remediation in flight

All four current Meraki admins authenticate via local Meraki Dashboard email/password. There is no integration with Okta (the organization's canonical identity provider for portal and infrastructure access). This results in:

  • No centralized account lifecycle (Okta deprovisioning does not remove Meraki access)
  • No platform-enforced MFA tied to Okta policies
  • Authentication audit trails fragmented between Okta logs and Meraki Dashboard event log
  • No role-based access provisioning via group membership

Remediation: Okta SAML SSO cutover documented in meraki-sso-runbook.md. Target completion: end of Q2 2026 (2026-06-30). Cutover converts all four current admins to SAML-based authentication via two Okta groups (apps-meraki-admins, apps-meraki-readonly), eliminating four local admin records (retaining one named break-glass on the IT Security Lead's account for the initial 30-day post-cutover stability window).

MERAKI-2026-04-003 — End-of-support hardware in inventory

Severity: Critical Status: ACTIVE — decommission queued

Two access points are operating past end-of-support (2024-07-31, ~21 months stale at discovery):

Hostname Serial Model EoS Date Network Assignment
mdec garage Q2JD-29US-5JXK MR32 2024-07-31 Unassigned
mdec 1st floor work room Q2JD-2MFW-39AG MR32 2024-07-31 Unassigned

Both devices are unassigned to any production network (networkId: null at discovery), indicating they may already be operationally decommissioned but remain claimed to the organization. No firmware updates, security patches, or vendor support are available.

Remediation: Decommission both devices from the Meraki organization. Approximate effort: 5-minute Dashboard operation. Owner: IT Security Lead. Target: 2026-05-31.

MERAKI-2026-04-004 — Approaching end-of-support cliff

Severity: High Status: ACTIVE — replacement planning in flight

Twelve access points across three sites reach end-of-support on 2026-07-21 — approximately 10 weeks from this review's reassessment date:

Site Devices Models
MDEC 3 MR52
OAKEC 2 MR52
DC Apartments 4 MR52 (1), MR33 (3)
Unassigned (decommission queue) 3 MR52 (1), MR33 (1), MR32 (2)

Beyond 2026-07-21, these devices will receive no further firmware or security updates from Cisco.

Remediation: Hardware replacement strategy required by 2026-06-15 to allow procurement lead-time. Decision pending between (a) like-for- like replacement to current-gen MR (MR46/MR56 generation) and (b) re-evaluation of wireless coverage requirements per site. Owner: IT Security Lead in coordination with Procurement.

MERAKI-2026-04-005 — Switch end-of-sale procurement window

Severity: Medium Status: CLOSED — explicit attrition-driven replacement strategy

Thirteen switches reached end-of-sale on 2026-04-30:

Site Devices Models
WDC-Eye Street 7 (stack) + 2 (edge) MS225-48 (4), MS225-48FP (3), MS120-8 (2)
MDEC 1 MS210-24P
OAKEC 1 MS210-24P
Plus 2 additional MS210/MS225 distribution

After 2026-04-30, no new units of these SKUs are available for procurement. Existing units continue to receive firmware and support under their licensing terms.

Decision (2026-05-07): Adopted attrition-driven replacement strategy. No spares were procured before the end-of-sale window. As units fail, they will be replaced with current-generation Meraki switches matching the operational role. Residual risk: extended recovery time during the period between failure and replacement delivery for affected sites. Acceptance: the WDC switch stack operates as N+1 from a port-density standpoint, providing partial redundancy for individual member failure; MDEC and OAKEC each operate with a single distribution switch where failure produces site outage pending replacement.

Documented decision-maker: IT Security Lead (Rajesh Chhetry) in consultation with Procurement, 2026-04-30 deadline window.

MERAKI-2026-04-006 — Unassigned device hygiene

Severity: Medium Status: ACTIVE — combined with MERAKI-2026-04-003 decommission

Three devices have networkId: null in the org inventory — claimed to the organization but not assigned to any production network. Two are also captured under MERAKI-2026-04-003 (past end-of-support); the third is operationally valid but requires either re-assignment or removal.

Hostname Serial Model Disposition
mdec garage Q2JD-29US-5JXK MR32 Decommission (per -003)
mdec 1st floor work room Q2JD-2MFW-39AG MR32 Decommission (per -003)
mdec 2nd floor by the bunk room Q2PD-L4QQ-9G54 MR33 Either reassign to MDEC or decommission

Remediation: Combined with MERAKI-2026-04-003 decommission session. Decision on the MR33 (reassign vs. decommission) pending review of MDEC coverage map.

MERAKI-2026-04-007 — No syslog forwarding to SIEM

Severity: High Status: ACTIVE — Meraki Wave 4 telemetry workstream

Meraki devices currently do not forward syslog to the GPUS-managed SIEM (CEDAR / Elasticsearch / Wazuh). This results in:

  • SIEM blindness to Meraki-side security events (admin logins, configuration changes, IDS alerts on MX appliances, VPN state changes, AP outage events)
  • No alert pipeline for Meraki-originated security signals
  • Audit log retention limited to Meraki Dashboard's default retention policies, with no GPUS-controlled long-term retention

Remediation: Telemetry integration deferred to Meraki Wave 4 (Q3 2026 target per Meraki domain roadmap). Will include syslog forwarding to CEDAR Logstash on port 5140, Wazuh decoder authoring at /var/ossec/etc/decoders/gpus-meraki-decoders.xml, Wazuh rule authoring at /var/ossec/etc/rules/gpus-meraki-rules.xml (rule numbers 100020+), Meraki API polling on MAPLE for state metrics not present in syslog, and Grafana dashboard for Meraki ops.

MERAKI-2026-04-008 — "DC Apartments" network name whitespace

Severity: Low Status: ACTIVE — cosmetic

The network name field for N_630503947831910695 contains trailing whitespace observable in some API responses but not in the Dashboard UI display.

Remediation: Trim whitespace at next maintenance window. Five- second Dashboard edit. No operational impact.

MERAKI-2026-04-009 — No formal change-control process

Severity: Medium Status: ACTIVE — process design pending

Meraki Dashboard configuration changes (firewall rules, network settings, SSID configurations, switch port profiles) are currently made directly by administrators with no formal change-control record: no change request, no peer review, no documented rollback plan, no post-change verification record.

This is a gap against CIS Control 4 (Secure Configuration of Enterprise Assets) and NIST 800-53 CM-3 (Configuration Change Control).

Remediation: Future-state goal is integration of Meraki changes into the GPUS-IT HappyFox-based change request workflow with peer review by Tanu Garg or designated alternate. Target: 2026-Q3, pending HappyFox integration completion (T4 dependency).

MERAKI-2026-04-010 — Audit log retention

Severity: Medium Status: ACTIVE — addressed by Wave 4 telemetry

Meraki Dashboard audit logs (admin actions, configuration changes) are retained per Meraki's default policies. There is no GPUS-managed long-term retention or backup of these logs, limiting forensic capability beyond Meraki's retention horizon.

Remediation: Combined with MERAKI-2026-04-007 — syslog forwarding to CEDAR will provide GPUS-controlled long-term retention. Target: Q3 2026 per Meraki Wave 4.

MERAKI-2026-04-011 — Audit-process gap on per-admin 2FA capture

Severity: Low Status: ACTIVE — process refinement for next review cycle

The 2026-04-27 admin discovery API call did not include the twoFactorAuthEnabled field per-admin. As a result, this review cannot evaluate whether locally-authenticated admins have 2FA enabled on their Meraki Dashboard accounts — a relevant data point for NIST 800-53 IA-2(1) (Multi-factor Authentication for Privileged Accounts) assessment.

Note: Post-SAML-cutover, MFA enforcement happens at the Okta layer (per Okta's group-policy configuration), so this gap is materially closed for the post-cutover state. Pre-cutover, current admins should verify 2FA is enabled on their local accounts as an interim measure.

Remediation: Future Meraki admin reviews will include per-admin twoFactorAuthEnabled capture in the discovery API call. Add to next quarterly review template. Owner: IT Security Lead.

Actions Taken

Action Status Date Owner
OAKEC firewall renamed (Justin-Bieber → oakec-fw-primary) Complete 2026-04-23 Rajesh Chhetry
Meraki API key rotation (prior key compromised by chat disclosure) Complete 2026-04-23 Rajesh Chhetry
Sedita access retained with documented justification Complete 2026-05-07 Rajesh Chhetry
MS225/MS210 attrition strategy decision Complete 2026-04-30 Rajesh Chhetry + Procurement
Documentation framework: meraki-infrastructure.md, hostregistry/meraki-hostregistry.csv, compliance/iar.md Meraki section Complete 2026-04-27/28 Rajesh Chhetry

Compliance Mapping

Framework Control Status Notes
CIS Controls v8 5 (Account Management) Partial — gaps in -001, -002, -011 SSO cutover closes -002; -001 closed; -011 process improvement
CIS Controls v8 6 (Access Control Management) Partial — gap in -002 RBAC two-tier model designed; pending SAML cutover
CIS Controls v8 4 (Secure Configuration) Gap — see -009 Change control process pending
NIST 800-53 AC-2 (Account Management) Compliant post-cutover All admins under managed identity provider
NIST 800-53 AC-6 (Least Privilege) Compliant Two-tier role model (full + read-only)
NIST 800-53 IA-2 (Identification and Authentication) Compliant post-cutover Local admin → SAML migration
NIST 800-53 IA-2(1) (MFA for Privileged Accounts) Compliant post-cutover Okta-enforced; see -011 for pre-cutover gap
NIST 800-53 CM-3 (Configuration Change Control) Gap — see -009 Process design in Q3 2026
NIST 800-53 AU-2 (Event Logging) Partial — see -007, -010 Local logging present; centralized aggregation in Q3 2026
ISO 27001:2022 A.5.15 (Access Control) Compliant post-cutover Identity-provider-based
ISO 27001:2022 A.5.18 (Access Rights) Compliant This review documents review cadence
PCI-DSS v4.0 Req 7 (Restrict Access) Compliant — Meraki not in CHD scope Two-tier role enforced
PCI-DSS v4.0 Req 8 (Identify and Authenticate) Compliant post-cutover Unique per-user identities, MFA via Okta

Sign-off

Role Name Signature Date
Author / Reviewer Rajesh Chhetry, IT Security Lead — 2026-05-07
Next review cycle Quarterly under access-review.md framework — 2026-07

References

Document History

Version Date Author Change
1.0 2026-05-07 Rajesh Chhetry Initial review. 11 findings documented (2 closed at publication, 9 active). Establishes quarterly cadence for Meraki admin access reviews under access-review.md framework.