The Meraki Enterprise Agreement (EA) is a licensing and entitlement framework that operates inside Cisco’s broader Enterprise Agreement model. It changes how Meraki licenses are consumed, tracked, and governed over time. It does not alter how Meraki features behave in the Dashboard, but it does impose structural rules on how hardware, licenses, and organizations interact throughout the agreement term.

This guide focuses on operational mechanics rather than justification. It covers scope boundaries, lifecycle behavior, and the constraints the model introduces in real environments.

Enterprise Agreement Scope for Meraki

The Enterprise Agreement does not apply universally across all Meraki products or licensing constructs. Those boundaries are fixed by the agreement structure rather than deployment intent. Knowing what is in scope prevents teams from assuming coverage that does not exist.

Included Meraki Product Families

Only specific Meraki product families can participate in an Enterprise Agreement. Eligibility is determined at the agreement level, not dynamically at the organization level. When included, these product families consume EA capacity once hardware is claimed and licensed.

Commonly included families are:

• MX and latest Cisco security and SD-WAN appliances

• MS switches

• Cisco Catalyst 9000 series switches

• MR wireless access points

• CW wireless access points

• MV cameras

• MT sensors

• Other new products

Inclusion alone does not trigger consumption. Enrollment and claim events still control usage.

Included Software and Support Entitlements

Within scope, the Enterprise Agreement governs cloud licensing and support entitlements associated with eligible hardware. These entitlements align to the EA term rather than individual license expiration dates.

Operationally, this means:

• License duration aligns to the agreement term.

• Support entitlement tracks with EA state.

• Feature availability remains unchanged.

The agreement affects accounting, not functionality.

Hardware Excluded From EA Coverage

Physical Meraki hardware is never licensed by the Enterprise Agreement itself. Devices are still purchased through standard Cisco ordering processes. They only interact with the EA after they are claimed into an enrolled organization.

This distinction matters during procurement planning and refresh cycles.

Licensing Models Not Covered by EA

Some licensing models and services remain outside the Enterprise Agreement regardless of scale or growth plans.

These exclusions typically include:

• Products not explicitly enrolled in the EA workspace.

• Licensing programs outside the EA construct.

• Organizations not associated with the agreement.

These boundaries do not change mid-term.

Meraki Enterprise Agreement Workspace

The EA Workspace is the authoritative control and visibility layer for Meraki participation in an Enterprise Agreement. It exists outside the Meraki Dashboard while integrating with Cisco’s EA systems.

EA Workspace Creation

The workspace is created as part of the Cisco Enterprise Agreement process and serves as the system of record for entitlement tracking. It is not created from within the Meraki Dashboard and cannot exist independently of an EA.

Once created, it becomes the reference point for all Meraki EA accounting.

Association to a Cisco Enterprise Agreement

Each workspace is bound to a single Cisco Enterprise Agreement, and that relationship cannot span multiple agreements. This association defines the term, committed quantities, and reconciliation behavior.

Meraki data flows into the workspace, not the other way around.

Enrollment of Meraki Organizations

Meraki organizations must be explicitly enrolled into the EA workspace before their license consumption is attributed to the agreement. Enrollment is a deliberate administrative action, not an automatic process.

Only enrolled organizations draw from EA capacity.

Visibility of Entitlements and Consumption

The workspace provides aggregated visibility into committed quantities, consumed quantities, and remaining capacity. This data reflects EA accounting systems and may lag behind Dashboard views.

Teams should treat the workspace as the source of truth for entitlement status.

Role and Permission Assignment

Access to the EA workspace is governed separately from Meraki Dashboard roles. Permissions control who can view consumption data, manage enrollments, and participate in reconciliation activities.

This separation often surprises teams who expect Dashboard admins to have EA visibility by default.

License Consumption and Tracking

License consumption under an Enterprise Agreement is event-driven and centrally accounted. It is not tied to traditional co-term calculations.

Events That Trigger License Consumption

Consumption occurs when eligible hardware is claimed into an enrolled organization and associated with active licensing. Inventory that is purchased but not claimed does not consume EA capacity.

Trigger events include:

• Claiming new hardware.

• Activating licenses for eligible devices.

Timing matters for capacity planning.

License Counting Method

Licenses are counted based on device type and entitlement definitions within the agreement. They are not based on Dashboard configuration changes or feature usage.

Counting behavior is consistent across organizations once enrolled.

Allocation of Consumption Across Organizations

Consumption is aggregated across all enrolled organizations rather than tracked independently per org. This allows flexibility but reduces per-org isolation.

Operational considerations include:

• Shared capacity pools.

• Centralized reconciliation.

• Limited per-org attribution detail.

Reporting Latency and Reconciliation

EA systems do not update in real time. Reporting latency between the Meraki Dashboard and EA workspace is expected and normal.

Teams should plan for:

• Periodic reconciliation cycles.

• Temporary discrepancies between systems.

• Formal true-up processes.

Co-Termination and Term Alignment

Meraki’s co-termination model still exists under an Enterprise Agreement. However, it is governed by the EA term rather than individual license timelines.

EA Term Start Behavior

At the start of the agreement, enrolled organizations align to the EA term regardless of prior co-term state. Existing licenses are absorbed into the agreement structure.

This alignment resets how expiration is evaluated.

EA Term End Behavior

As the agreement approaches expiration, license behavior is driven by the EA lifecycle state rather than device-level expiration dates. Renewal status becomes the controlling factor.

Effect of Mid-Term Hardware Adds

Hardware added mid-term automatically aligns to the existing EA term and draws down committed quantities. No additional license term calculations are required.

This simplifies expansion but increases reliance on capacity tracking.

Adding Capacity During the Agreement Term

Capacity expansion during an active Enterprise Agreement follows a predictable sequence. This sequence separates procurement from entitlement.

Claiming New Hardware Under an Active Agreement

Hardware is purchased independently, then claimed into an enrolled organization. Claiming is the moment when licensing behavior becomes relevant.

Unclaimed hardware remains neutral.

Automatic License Consumption Upon Claim

Once claimed, eligible devices immediately begin consuming EA capacity based on their product family and entitlement definitions. There is no manual activation step.

Incremental Drawdown of Committed Quantities

Each claim reduces remaining committed quantities in the workspace. Consumption accumulates across all enrolled organizations. Monitoring is required to avoid overages.

True-Up and Reconciliation Timing

True-ups occur on defined intervals based on agreement terms, not at the moment capacity is exceeded. Reconciliation aligns reported usage with contractual commitments.

This timing affects budgeting and renewal planning.

Renewal and Agreement Lifecycle

Enterprise Agreements move through defined lifecycle states. Each state has specific operational implications.

Active Agreement State

During the active state, licenses function normally and consumption draws against committed quantities without restriction. This is the steady-state operating condition.

Expiring Agreement State

As expiration approaches, visibility into consumption increases while licensing behavior remains unchanged. This period is informational, not restrictive. It is intended to support renewal planning.

Expired Agreement State

If the agreement expires without renewal, licensing behavior transitions according to Cisco policy, not Meraki co-term rules. Service continuity depends on agreement status.

This state requires immediate attention.

Common Operational Boundaries

Certain constraints exist regardless of deployment size or intent.

These include:

• No cross-org visibility outside enrolled organizations.

• Isolation between Meraki product families.

• Dependency on EA systems for entitlement truth.

• Gaps between workspace and dashboard data.

These are structural characteristics, not misconfigurations.

Differences Between EA and Standard Meraki Licensing

Enterprise Agreements and standard Meraki licensing operate on fundamentally different mechanics.

• Contract structure: Standard Meraki licensing is device-centric, with licenses tied to individual hardware. An Enterprise Agreement is commitment-based and governed by a single agreement term.

• License accounting model: Standard licensing tracks individual expiration dates per device. Enterprise Agreements track consumption against committed quantities over the life of the agreement.

• Expansion handling: Standard licensing expansion requires purchasing new licenses for added hardware. Enterprise Agreements draw down from existing committed capacity as devices are claimed.

• Renewal mechanics: Enterprise Agreement renewals apply to the agreement as a whole. Standard licensing is managed per device or per organization.

Scenarios That Require Extra Attention

Some operational changes intersect sharply with EA mechanics and require careful handling.

• Hardware refresh mid-term: Replacing hardware during an active EA can change how capacity is consumed. This makes refresh planning important before claims occur.

• Partial EA coverage: When only some Meraki organizations are enrolled, licensing behavior differs across environments. This requires deliberate separation to avoid incorrect assumptions.

• Merging organizations: Organizations must be enrolled into the EA workspace before a merge so license consumption is attributed correctly after consolidation.

• Splitting organizations: Splitting an enrolled organization can change how consumption is reported and reconciled. This is especially true if the resulting organizations are not treated consistently.

• Moving from standard licensing: Existing license states must be aligned during enrollment so consumption begins correctly under the EA without gaps or overlaps.

• Exiting the EA at renewal: Leaving an EA changes how licenses are governed going forward. This affects co-termination behavior and renewal planning.

• Changing product mix: Shifting between Meraki product families mid-term can alter consumption profiles. This may require agreement adjustments.

• Multiple EA realignment: Meraki organizations cannot participate in more than one EA at a time. Reassociation must be planned carefully to maintain entitlement accuracy.

Enterprise Agreements Set the Constraints Hardware Must Operate Within

An Enterprise Agreement does not change how Meraki hardware functions, but it defines the licensing boundaries hardware must operate within over the long term.

Adding or refreshing hardware changes how licensing behaves under the agreement. This makes understanding these mechanics essential before scaling.

Adding or refreshing hardware changes how EA licensing behaves. Learn how Cisco Meraki handles it before you scale.