Cisco Smart Licensing Guide: CSSM, SLUP, Compliance States, and Enterprise Management

Why Cisco Moved to Smart Licensing

The original Cisco licensing models — PAK (Product Authorisation Key) activation, node-locked licences tied to specific hardware serial numbers, and feature licence files installed on individual devices — were operationally complex at scale and created visibility gaps that made enterprise licence management difficult. An organisation with 500 Cisco switches, 100 routers, and 50 firewalls was managing thousands of individual licence files across dozens of product families with no centralised view of entitlement or compliance status.

Smart Licensing addressed this by creating a cloud-based licence management platform: Cisco Smart Software Manager (CSSM) at smart.cisco.com. Under Smart Licensing, software licences are associated with the customer's Smart Account rather than specific device hardware. Devices register to the Smart Account through an internet connection or proxy, report their licence consumption, and CSSM reconciles consumption against entitlement in real time. This created the centralised visibility that enterprise licence management requires, but introduced its own complexity around connectivity requirements and compliance state management.

Cisco Smart Software Manager (CSSM) Architecture

CSSM is the central management platform for all Cisco Smart Licences. Understanding CSSM's structure is essential for managing compliance and for optimising licence utilisation across the enterprise.

Smart Accounts and Virtual Accounts

Every organisation using Smart Licensing has a Smart Account, which is the top-level container for all Cisco licences purchased by that organisation. Within a Smart Account, administrators create Virtual Accounts to organise licences by business unit, geography, product family, or any other grouping that reflects the organisation's management structure.

Licences are assigned to specific Virtual Accounts, and devices register to a specific Virtual Account using a registration token generated from that Virtual Account in CSSM. When a device reports licence consumption, CSSM checks whether the Virtual Account it registered to has sufficient licence entitlement to cover the reported usage. This means that licence management in CSSM is not just at the Smart Account level — it requires careful allocation of licences across Virtual Accounts to match where devices are deployed and registered.

CSSM Connectivity Options

Cisco provides three options for connecting devices to CSSM, each suited to different security and network architecture requirements.

Direct Cloud Access: Devices connect directly to CSSM at smart.cisco.com over HTTPS. This is the simplest deployment model and requires only outbound internet access on TCP port 443. Appropriate for organisations without strict internet access restrictions on network infrastructure devices.

Cloud Access Through a Proxy: Devices connect to CSSM through a customer-managed HTTPS proxy. This accommodates organisations that require all internet traffic from infrastructure devices to traverse an inspection or logging proxy. The proxy must allow traffic to smart.cisco.com without SSL inspection that would break certificate validation.

Cisco Smart Software Manager On-Premises (SSM On-Prem): A customer-hosted server that acts as a local CSSM, synchronising periodically with the cloud CSSM. SSM On-Prem is deployed as a virtual appliance and is licensed by Cisco — the licence is free but must be ordered. Appropriate for air-gapped environments, highly security-conscious deployments, and organisations that cannot allow infrastructure devices direct internet access. SSM On-Prem adds operational overhead for installation, maintenance, and periodic synchronisation with cloud CSSM.

Classic Smart Licensing: Registration and Compliance

In classic Smart Licensing (the original framework before SLUP), devices must register with CSSM by submitting a registration token generated from the target Virtual Account. Registration establishes the authorisation relationship between the device and CSSM, and the device's licence status is determined by CSSM's reconciliation of reported consumption against Virtual Account entitlement.

Registration Token Lifecycle

Registration tokens are generated in CSSM under a specific Virtual Account. Each token has a configurable expiry window (1 to 365 days) within which devices must register using that token. Once a device registers, the token is no longer needed for that device — the registered relationship is maintained independently. Tokens can be reused for multiple device registrations until they expire, making them suitable for bulk deployment workflows.

For on-premises CSSM deployments, token generation is restricted to the local SSM On-Prem server. Tokens generated in cloud CSSM cannot be used to register devices to on-premises SSM, and vice versa. This separation must be planned during Smart Licensing architecture design to avoid mismatched registration environments.

Classic Smart Licensing Compliance States

Under classic Smart Licensing, devices operate in one of six compliance states that are visible in CSSM and affect device behaviour.

• Authorized: The device is registered and the Virtual Account has sufficient entitlement for the reported licence consumption. This is the expected steady state for compliant deployments.
• Out of Compliance: The device is registered but the Virtual Account has insufficient entitlement. This is the primary compliance exposure state — the device is consuming licences it is not entitled to. Under classic Smart Licensing, certain features may be restricted after an out-of-compliance period, though the grace period varies by product.
• Eval Mode: The device has not yet registered with CSSM and is operating under a default evaluation period (typically 90 days). Features operate normally during eval mode, but the evaluation period does not pause and devices that never register will eventually exhaust the eval period.
• Eval Expired: The evaluation period has elapsed without registration. Feature availability depends on the specific product's behaviour — some products restrict features aggressively, others provide a further grace period.
• Unidentified: CSSM cannot identify the product or its licence requirements. Usually indicates a configuration issue or an unsupported product version.
• No Licences in Use: The device is registered but reporting zero licence consumption, typically for hardware-only devices without active software feature licences.

Smart Licensing Using Policy (SLUP): The New Framework

Smart Licensing Using Policy (SLUP) is a significant evolution of the Smart Licensing model, introduced for Cisco IOS XE 17.3.2 and later, and for Cisco Catalyst switching platforms from specific software releases onwards. SLUP fundamentally changes the compliance model: rather than requiring registration before features can be used, SLUP allows devices to operate from day zero without registration, with a reporting obligation to send usage data to CSSM within defined reporting intervals.

The Day Zero Deployment Advantage

Under classic Smart Licensing, a newly deployed device that cannot reach CSSM to register will begin consuming its evaluation period immediately. If network architecture prevents registration (air-gapped network, proxy misconfiguration, CSSM connectivity issue), the device enters a timed countdown toward feature restriction. SLUP eliminates this operational friction: devices operate fully from first boot without registration, without evaluation periods, and without connectivity to CSSM being required for initial deployment.

This is particularly valuable for large-scale switch deployments, branch router rollouts, and zero-touch provisioning (ZTP) scenarios where network connectivity may not be fully established at the time of initial device configuration.

SLUP Reporting Obligations

The trade-off for SLUP's operational flexibility is a reporting obligation. Under SLUP, devices must send licence usage reports to CSSM at intervals defined by policy. The default reporting interval for most products is 90 days, meaning that even without persistent connectivity, devices must have a reporting event within every 90-day window.

Reporting can occur through three mechanisms: direct cloud synchronisation (if the device has internet access), transport through Cisco SSM On-Prem followed by cloud synchronisation, or manual export of usage data from the device using the show license all command and import into CSSM. The manual process is operationally burdensome at scale but is available for environments where automated reporting is not possible.

SLUP Policy Hierarchy

Under SLUP, the behaviour of each device is governed by a licence policy, which defines reporting intervals, the grace period for missed reports, and whether certain licence types require authorisation before use (an optional restriction for high-value licences). The policy hierarchy is: Cisco Default Policy (the baseline Cisco defines), Customer-Specific Policy (negotiated with Cisco for specific customers or use cases), and Device-Level Policy (applied to specific devices as overrides). Most enterprise customers operate under the Cisco Default Policy unless they have negotiated specific terms.

CSSM Virtual Account Management Best Practices

Effective Smart Licensing compliance management at enterprise scale requires deliberate Virtual Account architecture and ongoing licence reconciliation. The following practices represent the approach we recommend to clients managing large Cisco estates.

Virtual Account Design Principles

Virtual Accounts should map to the natural management boundaries of the organisation — typically business units, geographies, or data centre regions. Avoid creating Virtual Accounts that are too granular (one per site for a 200-site network creates unmanageable fragmentation) or too broad (a single Virtual Account for all licences loses visibility into where licences are consumed). A practical enterprise design typically uses five to twenty Virtual Accounts covering major organisational divisions and product families.

Licence pools within Virtual Accounts should include a reasonable buffer above current consumption — typically 10 to 15 percent — to accommodate device additions, licence upgrades, and the reporting window during which newly deployed devices appear as consumed without an immediate licence transfer. Insufficient buffer creates false out-of-compliance alerts that obscure genuine compliance issues.

Regular Compliance Reconciliation

Smart Account administrators should review CSSM compliance status quarterly at minimum, and before every major refresh or expansion project. Key review items include: Virtual Accounts with out-of-compliance devices, devices in eval mode that should be registered, devices with missed reporting events under SLUP, and licence pools that are approaching or exceeding their committed quantities. CSSM provides dashboards and exportable reports that support this reconciliation process.

Smart Licensing and Enterprise Agreement Renewals

Cisco's EA renewal process involves a True-Forward event where Cisco's account team compares the licence consumption recorded in CSSM against the committed licence quantities in the EA. Organisations that have deployed more licences than committed — or that have not properly registered or reported consumption, creating gaps in the CSSM consumption record — face different renewal dynamics.

Organisations with accurate CSSM records that show consumption below the EA committed quantities enter renewal in a strong position: they have documented their licence utilisation and can argue for reduced quantities at renewal, or redirect spending toward new capability areas. Organisations with poor CSSM hygiene — devices in eval mode, unregistered products, SLUP reporting failures — present an unclear picture that Cisco's account team may interpret conservatively, leading to renewal pressure on quantities that are not genuinely required.

Conducting a Smart Licensing compliance review as part of EA renewal preparation is a standard component of our Cisco advisory engagements. The review identifies devices out of compliance, licence pools that are over-committed or under-utilised, and reporting gaps that should be resolved before Cisco's account team conducts their own True-Forward review.

Real-World Cisco Smart Licensing Engagement

In one engagement, a Fortune 500 financial services firm was preparing for a Cisco EA renewal and discovered their Smart Licensing records showed 847 devices in an out-of-compliance state — consuming more licences than they had committed to purchase. The compliance exposure exceeded 2.3 million USD in unbudgeted licence costs. Our engagement identified that the Virtual Account allocation across their 40+ business units had become fragmented during a two-year period, with no centralised visibility of entitlement or deployment. We restructured their Virtual Account hierarchy, realigned registrations, and established automated compliance monitoring. The financial exposure was eliminated, and they entered EA renewal with defensible, accurate consumption records. The engagement fee was less than 5% of the initial exposure value.

Transitioning from Classic Smart Licensing to SLUP

Organisations running Cisco software platforms eligible for SLUP need to plan the transition carefully, particularly when the network includes a mix of classic Smart Licensing and SLUP-capable devices. Key transition considerations include:

• Software version requirements: SLUP requires specific minimum IOS XE, NX-OS, or platform software versions. Confirm eligibility before planning the transition.
• SSM On-Prem version compatibility: If using on-premises CSSM, verify that the SSM On-Prem version supports SLUP before upgrading edge devices.
• Reporting interval planning: Configure CSSM communication schedules to meet SLUP reporting obligations before the first 90-day reporting window expires post-transition.
• Parallel compliance monitoring: During a mixed-environment transition period, monitor both classic registration states and SLUP reporting states in CSSM to maintain complete compliance visibility.
• EA implications: If the organisation has an EA, notify the Cisco account team of the SLUP transition timeline to ensure the True-Forward process reflects the new compliance model.

Smart Licensing Across Cisco Product Families

Smart Licensing implementation varies across Cisco's product families, and organisations with mixed estates must understand the differences to maintain accurate compliance records across the full deployment.

Cisco Catalyst and Nexus Switching

Cisco Catalyst 9000 series switches and Nexus data centre switches support Smart Licensing and, in recent software releases, SLUP. DNA licence tiers (Essentials, Advantage, Premier) are reported through Smart Licensing, and the switch hardware's Network Essentials or Network Advantage tier is separately tracked. Organisations that have recently refreshed campus or data centre switching should verify that the DNA tier reported in CSSM matches the purchased entitlement — mismatches between deployed DNA tier and registered tier are a frequent compliance issue in post-refresh environments.

Cisco ISR and ASR Routing Platforms

IOS XE-based ISR and ASR routers were among the first platforms to implement SLUP (from IOS XE 17.3.2 onwards). For these platforms, technology packages (Security, Data, Unified Communications) are reported as licence consumption events in CSSM. Organisations running legacy IOS (not IOS XE) on older ISR G2 platforms use classic PAK or Right-to-Use licensing that is not visible in CSSM — a split-management situation that requires careful documentation until those platforms are retired or upgraded.

Cisco Firepower and Secure Firewall

Cisco Secure Firewall (FTD — Firepower Threat Defence) uses Smart Licensing for threat, URL, and malware subscription licences. Firepower Management Centre (FMC) manages the Smart Licensing registration for all managed FTD appliances, meaning that CSSM connectivity requirements apply to FMC rather than directly to individual firewalls. In clustered FTD deployments, only the primary FMC registers with CSSM and reports consumption for all managed appliances. Organisations that have FMC deployed behind strict outbound internet controls must ensure FMC's connectivity to CSSM or SSM On-Prem is explicitly allowed.

Cisco Collaboration Platforms

Cisco Unified Communications Manager (CUCM), Cisco Expressway, and other on-premises collaboration platforms use Smart Licensing for software feature tracking. Collaboration subscription licences (Flex Plan tiers, Enhanced Plus, Meetings) are reported through Smart Licensing and reconciled against the EA commitment or standalone subscription purchase. Collaboration platforms that are several major releases behind current versions may not support Smart Licensing and require firmware upgrades before Smart Account integration is possible.

Smart Licensing in Mergers, Acquisitions, and Divestitures

Cisco Smart Account structure must be actively managed during corporate transactions. When two organisations with Cisco estates merge, their respective Smart Accounts must be consolidated, Virtual Account structures harmonised, and licence entitlements transferred to the correct accounts for the combined entity. Failure to manage Smart Account consolidation results in licence pools that appear over-committed because consumption is split across two accounts rather than consolidated in one, and because device registrations from the acquired entity point to a Smart Account that may no longer be appropriately resourced.

Cisco's Smart Account team provides guidance and tooling for Smart Account mergers, but the commercial implications — particularly around EA scope, licence quantity reconciliation, and renewal timing — require advisory that is independent of Cisco to ensure that the post-merger licensing structure reflects market pricing and buyer-side interests rather than Cisco's preferred expansion narrative.

Divestitures present the inverse challenge: licences and devices must be transferred from the corporate Smart Account to the divested entity's new or existing Smart Account, often under time pressure from transaction close timelines. This requires careful pre-transaction planning of which licences, Virtual Accounts, and device registrations belong to the divested business, and a transfer process that preserves compliance continuity without creating gaps in the divested entity's licence coverage.

Common Smart Licensing Mistakes in Enterprise Environments

Enterprise organisations consistently encounter the same Smart Licensing management failures. Understanding these failure patterns supports proactive management.

• Virtual Account fragmentation: Creating too many Virtual Accounts leads to licence pool fragmentation where individual accounts have insufficient buffer for new deployments, creating false out-of-compliance states.
• Registration token expiry management: Failing to track registration token validity periods leads to deployment workflows that use expired tokens, causing registration failures during network expansion.
• SSM On-Prem synchronisation failures: On-premises CSSM installations that are not synchronised to cloud CSSM for extended periods accumulate stale compliance states. Synchronisation schedules should be automated and monitored.
• SLUP reporting gaps: Devices transitioning to SLUP without configured reporting intervals miss the 90-day reporting obligation. The absence of a missed reporting penalty does not mean the licence record is accurate — CSSM will not accurately reflect consumption without reporting.
• Incorrect product registration: Registering Cisco devices to a Virtual Account in the wrong product family results in licence consumption being attributed to the wrong pool. This creates out-of-compliance states in the correct pool even when sufficient overall entitlement exists.