License expiry silently disabling features: monitor days-to-expiry
Your firewall dashboard shows green. Interfaces are up, CPU and memory are normal, traffic is flowing. But at 09:00, someone reports VPN connections failing, IPS no longer blocking threats, or URL filtering not enforcing policy. A feature license expired at midnight, and the device silently stopped performing the licensed function without raising a visible alarm.
The device stays up, counters keep incrementing, throughput looks normal. The license-expiry message in syslog is low severity and gets buried under routine noise. By the time someone notices, the feature has been disabled for hours.
The fix is proactive monitoring of days-to-expiry as an operational signal, with thresholds that trigger procurement action well before expiry. This article covers the failure pattern, vendor-specific behaviors, quick checks, diagnostic steps, and the monitoring signals you need.
What this looks like in production
When a security or routing feature license expires, the feature stops functioning but the device remains operational. No reboot, no interface flap, traffic keeps flowing. What changes is that the licensed inspection, enforcement, or connectivity function silently degrades or stops entirely.
The failure is silent because the signals operators typically watch say nothing is wrong:
- No SNMP trap or syslog alarm fires on most platforms. PAN-OS does not generate a syslog or trap when a license silently expires. You must poll proactively.
- The license-expiry message in syslog is low severity (often INFO or WARNING) and gets buried under routine log noise.
- Feature-specific counters can be misleading. Traffic counters show traffic flowing through the feature, but the feature’s action counters (IPS drops, blocked connections) drop to zero.
- Grace periods mask the problem. Many vendors offer a grace period during which the feature continues working, creating a false sense of security that expires silently.
flowchart TD
A[License subscription lapses] --> B[Device receives no renewal signal]
B --> C{License server reachable?}
C -- No --> D[Device enters grace period]
C -- Yes --> E[Feature disabled at expiry boundary]
D --> F[Grace period expires]
F --> E
E --> G[Device stays UP, traffic flows]
G --> H[Feature action counters drop to zero]
H --> I[No SNMP trap fires on most platforms]
I --> J[Syslog logs low-severity message]
J --> K[Users report issue at 09:00]
K --> L[Operator discovers hours of silent disablement]Common causes
| Cause | What it looks like | First thing to check |
|---|---|---|
| Subscription lapsed (procurement gap) | Feature stopped working, license shows expired on device, renewal was due but not processed | Vendor portal for contract status |
| License server unreachable | Device in grace period or non-compliant state, intermittent feature failures | Connectivity from device to vendor license server |
| License count exceeded | Some devices in a fleet work, others do not, license pool insufficient | Vendor portal for seat allocation vs consumption |
| Auto-renewal failure | License was set to auto-renew but payment failed or card expired | Billing or procurement system for failed transactions |
| Device relocated or HA role changed | License binding broken after network change or failover | Device config for management interface and HA state |
| Reload after license server outage | Device was working in grace period, reload triggered re-evaluation and feature stopped | Device license state for authorization changes |
Quick checks
These are safe, read-only commands to check license state across common platforms.
# PAN-OS: query license state via XML API
# WARNING: the API key appears in the URL and will be logged in shell history.
# Consider using the X-PAN-KEY header instead of the key= parameter in production.
curl -sk "https://<fw>/api/?type=op&cmd=<request><license><info/></license></request>&key=<apikey>"
# PAN-OS: batch license query across all managed firewalls via Panorama
curl -sk "https://<panorama>/api/?type=op&cmd=<request><batch><license><info></info></license></batch></request>&key=<apikey>"
# Cisco IOS-XE: summary of all license entitlements
ssh <device> 'show license summary'
# Meraki: aggregated license state per organization
curl -s -H "Authorization: Bearer $KEY" \
https://api.meraki.com/api/v1/organizations/$ORG/licenses/overview
# Cato: license status via GraphQL API
curl -s -H "x-api-key: $KEY" -H "Content-Type: application/json" \
-d '{"query":"{ licensing(accountId: \"<id>\") { status } }"}' \
https://api.catonetworks.com/api/v1/graphql2
For the PAN-OS API key, generate it first with admin credentials:
# WARNING: password appears in the URL and will be logged in shell history and proxy logs.
# Use this only on a trusted workstation, or prefer key-based authentication via the GUI.
curl -k "https://<fw>/api/?type=keygen&user=<user>&password=<password>"
The PAN-OS API key can be passed as the X-PAN-KEY header or as the key= query parameter.
How to diagnose it
Identify which feature stopped working. Correlate user reports with the specific licensed function (VPN, IPS, threat prevention, URL filtering, SD-WAN). This narrows the license scope.
Check license state on the device. Run the platform-specific command from the quick checks above. Look for expired flags, grace-period indicators, or authorization state changes.
Correlate feature-disable time with license-expiry time. If IPS drops went to zero at midnight and the IPS license shows expired as of that date, you have confirmed the root cause.
Verify feature-specific action counters. Traffic through the feature should be non-zero, but the feature’s action counters (drops, blocks, matches) should be zero. On a PAN-OS firewall with expired Threat Prevention, the IPS drop count will be zero despite traffic flowing through the policy.
Check syslog for license-related messages. Search for keywords like “license”, “expired”, “subscription”, or “entitlement”. On PAN-OS you will not find a specific license-expiry syslog message. The absence of a message does not mean the license is valid.
Verify license server reachability. If the device phones home for license validation, confirm it can reach the vendor’s license server. A blocked or unreachable license server will silently degrade features after the grace period.
Check for reload-induced license state changes. On Cisco Firepower appliances, a reload after a software upgrade can reset license entitlement duration, triggering a 90-day evaluation period. In HA setups, if the primary unit reboots and loses authorization before communicating with Cisco, both units may enter evaluation mode simultaneously.
Vendor-specific silent-disable behaviors
Each vendor handles license expiry differently. Understanding these differences is critical for building effective monitoring.
Palo Alto Networks (PAN-OS 10.2)
PAN-OS begins logging a daily warning in the system log 30 days before expiry. The warning repeats daily until renewed or expired. Expiry is calculated at 12:00 AM GMT the day after the stated end date, regardless of configured timezone.
Specific feature behaviors on expiry:
- Threat Prevention / Advanced Threat Prevention: Existing signatures remain usable after expiry. However, installing a new Applications-only content update after expiry silently deletes all pre-existing threat signatures, leaving the device unprotected with no explicit warning.
- WildFire: Reverts from 5-minute signature updates to 24-48 hour updates silently. Advanced file forwarding stops without notification. The GUI shows WildFire as “enabled” while receiving drastically reduced protection.
- URL Filtering / Advanced URL Filtering: Stops connecting to the PAN-DB cloud database. Custom URL categories still enforce, but real-time cloud lookup does not occur.
- GlobalProtect: Core Windows and macOS client continues working. Linux client, mobile apps, IPv6, HIP checks, and Clientless VPN are silently disabled.
- Strata Logging Service: Read access continues for 30 days after expiry. Ingest and forward silently stop after the grace period.
- Support contract: Completely silent disable. No software updates, VM image downloads, or access to technical support.
PAN-OS does not expose license status via a standard SNMP OID. License expiry generates an incident via the AIOps for NGFW alerting pipeline, not via SNMP. Operators relying solely on SNMP will not receive proactive license warnings.
Fortinet FortiGate (FortiOS 7.4.4)
The device continues functioning as a firewall even with all FortiGuard licenses expired. Basic routing, NAT, and VPN (IPsec and SSL VPN) remain operational. Valid FortiGuard licenses are required for database and signature updates and for real-time security lookups.
Features that stop without valid licenses: antivirus scanning, IPS inspection, web filtering, DNS filtering, email filtering, and OT threat definitions. Custom or static rules for IPS and URL filtering can still apply, providing limited fallback protection.
After renewing a license on the FortiCloud account, the FortiGate may continue showing the license as expired until a manual refresh is triggered. Operators have reported waiting hours or days before the status updates automatically.
Cisco ASA / Firepower (Smart Licensing)
Cisco Smart Licensing uses a 90-day authorization period. If the device cannot communicate with Cisco for 90 days, the authorization enters AUTH EXPIRED state. During the evaluation period (approximately 90 days), the device operates in EVALUATION MODE with standard entitlements available.
Out-of-Compliance (OOC) conditions arise from over-utilization, license expiration, or inability to reach the Licensing Authority. When OOC, existing features continue operating, configuration changes to features requiring special licenses remain possible, but new contexts beyond Standard license limits cannot be added.
Communication deadlines occur every 30 days by default. Missing a deadline does not immediately disable features but triggers OOC state. Health Monitor alerts for Smart License status can be configured via FMC, supporting syslog, email, and SNMP trap notifications.
On Firepower 9300 and 4100 platforms, chassis SNMP MIBs must be configured on the MIO or chassis manager separately from FTD/ASA SNMP configuration.
Metrics and signals to monitor
| Signal | Why it matters | Warning sign |
|---|---|---|
| License days-to-expiry (per feature) | Leading indicator of impending silent disablement | Days-to-expiry dropping below 30 |
| Grace-period state | Feature is already disabled but still appears functional | Grace period active on any security-critical feature |
| Feature-specific action counters | Confirms whether the licensed function is actually working | IPS drops at zero while traffic through the policy is non-zero |
| License server reachability | Devices that phone home degrade silently if server is unreachable | Intermittent or failed authorization checks |
| Syslog license-related messages | Low-severity messages that are easy to miss | Any message containing “license”, “expired”, or “subscription” |
| Device authorization state (Cisco) | Tracks compliance and evaluation mode transitions | State change from AUTHORIZED to EVALUATION or OOC |
Fixes
License expired (procurement gap)
Immediate: Apply or reactivate the license through the vendor portal. For PAN-OS, install the new license key after obtaining it from the support portal. For Cisco, ensure Smart Software Manager has the correct token and the device can reach the licensing server.
If the license server is unreachable: Restore connectivity first. The device will remain in grace period until either the server is reachable or the grace period expires. Isolate the device if the disabled feature is security-critical.
Tradeoff: Re-licensing a large fleet takes time. Prioritize security-critical devices (edge firewalls, Internet-facing IPS) first.
WildFire or threat signature silent downgrade (PAN-OS)
Critical warning: Do not install a new Applications-only content update after Threat Prevention license expiry. Doing so silently deletes all pre-existing threat signatures, leaving the device fully unprotected. Verify license state before pushing any content update.
After renewal: Verify WildFire has resumed 5-minute updates and threat signatures are current. Check WildFire cloud connectivity status in the device GUI or via API.
FortiGate license refresh lag
After renewing on the FortiCloud account, trigger a manual license refresh on the device. Do not assume the status will update automatically within a useful timeframe.
Cisco reload-induced evaluation mode
In HA or failover scenarios, a planned upgrade that triggers reload can cause both units to enter evaluation mode simultaneously if the primary loses its authorization before communicating with Cisco. Plan upgrades with awareness of this behavior and verify license state after every reload.
Prevention
- Monitor days-to-expiry as an operational signal. Treat it with the same rigor as CPU, memory, and interface status. Poll it from the vendor API or CLI, not just syslog.
- Set alerting thresholds with procurement lead time. Alert at 30 days (TICKET for renewal action), escalate at 7 days (PAGE for immediate action), and treat any grace-period state on a security-critical feature as an immediate PAGE.
- Expose days-to-expiry as a gauge metric. A common pattern is a custom collector exposing
license_days_remainingas a gauge per device and per feature, updated by a scheduled script that queries each vendor API. - Validate feature-specific counters after license events. After any license renewal or expiry, verify that the feature’s action counters are non-zero while traffic is flowing. This catches silent downgrades like WildFire reverting to 24-48 hour updates.
- Do not rely on syslog alone. PAN-OS does not generate a license-expiry syslog message. FortiGate dashboard notifications are visible but not machine-actionable. Poll proactively.
- Track Smart License authorization state continuously. Cisco devices can enter EVALUATION MODE or OOC state after reloads or during license server outages. Monitor the authorization state, not just the feature status.
- Connect procurement systems to operational monitoring. The gap between procurement (contract management) and operations (device monitoring) is where most license-expiry incidents originate. Integrate contract data into monitoring alerts.
How Netdata helps
- Custom collector integration. Netdata’s collector framework can run scheduled scripts that query vendor APIs (PAN-OS XML API, Meraki Dashboard, Cato GraphQL, Cisco CLI) and expose
license_days_remainingas a gauge metric per device and per feature. - Threshold-based alerting. Configure alerts at 30 days (TICKET), 7 days (escalation), and grace-period state (PAGE) using standard Netdata alarm configuration. These thresholds map directly to procurement lead times.
- Signal correlation. Correlate license expiry events with feature-specific counters (IPS drops, VPN connection counts, threat prevention blocks). A license expiry alert that coincides with a feature counter dropping to zero confirms silent disablement. A license expiry alert with counters still active means the grace period is running.
- Syslog integration. Netdata’s syslog collector ingests device logs and can trigger on license-related messages. For vendors that do emit syslog or dashboard notifications, this provides an additional detection layer.
- Cross-device fleet views. Track license state across the entire fleet in a single dashboard to identify which devices are approaching expiry and prioritize renewal action.
Related guides
- ARP cache staleness: when IP-to-MAC mapping goes bad
- Asymmetric routing: why your path and latency measurements lie
- Audit log gaps: detecting syslog/trap tampering or loss
- BGP flapping: why a peer keeps resetting and how to find the cause
- BGP NOTIFICATION and Cease messages: what each subcode is telling you
- BGP RIB and FIB growth: monitoring route-table size before it bites
- BGP route leak and hijack: the detection signals and alerts that matter
- BGP session Established but stale: detecting silent route loss
- Correlating cloud VPC flow logs with on-prem NetFlow
- Cold-start topology: why your map is incomplete after a collector restart
- Collector CPU and TSDB write-queue saturation: the capacity signals
- NIC RSS misconfiguration: one CPU core silently dropping your telemetry







