Most outages and audit findings on network gear trace back to a config change nobody remembers making. Innovexus baselines every device on a schedule, compares against the last known-good, and alerts on any drift — authorised or not. Works across Cisco IOS, NX-OS, IOS-XR, Junos, FortiOS, Arista EOS, and everything else that exposes a CLI over SSH.
A change-window engineer pastes 30 lines of config at 2 AM. Twenty-eight lines work. Two have a typo. Three weeks later, an unrelated event triggers the failure mode those two lines created. Triage takes hours because nobody can quickly answer "what changed and when."
The change ticket says "deploy ACL revision 4.2 to perimeter routers." The actual `running-config` contains revision 4.1 plus three engineer-added comments and a temporary workaround that nobody removed. The discrepancy is invisible until something breaks.
A senior engineer eyeballing `show running-config | diff` against last quarter's archive catches some drift. They miss most of it. And nobody runs that comparison unless an outage forces it.
NERC CIP-010-3 R1 (configuration change management) requires a defined baseline and documented changes for BES Cyber Systems. SOC 2 CC8.1 requires change management for production systems. ISO 27001 A.12.1.2 is similar. "Vendor diff every quarter" rarely passes these as documented.
Rancid, Oxidized, and Git-based config archive tools work — but operating them at scale is a project. Storage management, alerting integration, multi-vendor parsing, retention, and access control to the archive are all DIY. Most teams that adopt them eventually drop them when the responsible engineer leaves.
Innovexus pulls every device's running config on a schedule, computes a diff against the last known-good baseline, and alerts on drift. The baseline updates only when a change is approved through the platform — drift detected outside that workflow surfaces immediately. The full archive is searchable, signed, and retained per the customer's policy.
Cisco IOS / IOS-XE / NX-OS / IOS-XR, Juniper Junos, Arista EOS, FortiGate FortiOS, Palo Alto PAN-OS, HPE/Aruba ArubaOS, Extreme EXOS, and any device exposing CLI over SSH. The pod's collector understands each vendor's config sanitisation (strip dynamic timestamps, banner sequence numbers, ARP entries — only structural config is diffed).
Default 4-hour polling; configurable from 15 minutes to 24 hours per device class. Critical perimeter devices typically run 15–60 minute cycles. Edge devices on a quieter polling interval. Schedule respects the device's typical change cadence and link cost.
When an engineer applies a change through an Innovexus brokered session, the platform offers to promote the post-change config as the new baseline (with the change-ticket reference attached). Drift detected in any subsequent collection that doesn't match the approved baseline raises an alert.
Drift events fire to the Innovexus SOC workspace, plus configurable webhook destinations: PagerDuty, Slack, Teams, Opsgenie, generic webhook. Severity is set per device class — perimeter drift on a Saturday at 3 AM is a P1; quiet-hours edge-switch drift is a low-priority queue item.
Every collected config is hash-chained and signed by the per-tenant pod. The archive is integrity-verifiable and retained for the configured period (default 7 years for the audit metadata, 90 days for full configs, configurable). Auditors get a read-only role with search and export.
Most teams have drift detection running across the fleet within 1 day. Here's the actual sequence.
Provision the per-tenant pod. Vault the device admin or read-only credentials the collector will use (a read-only TACACS+ user is sufficient for collection — the collector never needs config write).
Import device inventory from your existing source — CMDB, NetBox, ServiceNow, or a CSV. Devices group by class (perimeter, core, edge, distribution, OOB) so polling schedules and severity rules can be applied per group.
The collector pulls every device's running config on first contact and stores it as the initial baseline. This typically takes 5–30 minutes for a 500-device fleet. The baseline is the reference for future diffs.
Set polling cadence per device class. Configure alert destinations (Slack, PagerDuty, webhook). Set severity rules — e.g., any drift on devices tagged "perimeter" is P1 regardless of hour.
Drift detected outside an approved change fires the alert. Drift inside an approved change auto-promotes the baseline. Search the archive any time for "every config change to device X in the last 90 days" or "every device that had drift in the last hour."
Drift detection has been a category for two decades. Honest read on where Innovexus fits.
Rancid is the original config diffing tool. Free, scriptable, used by many ISPs. Trade-offs: operational burden (Perl, CVS/SVN/Git backend, manual alerting integration), limited multi-vendor support without scripting, no integrated PAM or session model. Works for teams with the operational maturity to maintain it.
Oxidized is the newer Ruby-based replacement for Rancid. Cleaner config, better multi-vendor support, REST API, web UI. Same fundamental DIY trade-off: you operate it, monitor it, integrate it with alerting and audit. Strong choice if you have the engineering bandwidth and prefer self-hosting.
SolarWinds NCM has solid config archive and drift alerting. Trade-offs: enterprise pricing (typically $20K–$60K/yr depending on device count), Windows-centric installation, broader SolarWinds suite that pulls in features you may not want. Best fit when SolarWinds is already the network management platform of record.
DNAC includes config compliance and drift detection for Cisco devices managed under DNAC orchestration. If you're a pure-Cisco shop already running DNAC, this is bundled. For multi-vendor environments or teams not committed to DNAC, separate tooling fits better.
Direct answers — written so each passage stands alone for AI-engine citation.
Default polling cadence is 4 hours; configurable from 15 minutes to 24 hours per device class. Most teams run perimeter and core at 15–60 minutes, edge and distribution at 4 hours, and out-of-band management devices on a slower cycle. Polling cadence is per device class, not per device, so changes propagate cleanly.
A read-only TACACS+, RADIUS, or local user is sufficient — the collector never writes config. Most teams use the same role-based account model as their ISE deployment, with a dedicated `innovexus-collector` role mapped to read-only privileges. Credentials are vaulted; rotation runs on schedule like any other vaulted credential.
When an engineer applies a change through an Innovexus brokered session and the change ticket is referenced, the platform offers to promote the post-change config as the new baseline. The promotion preserves the original baseline as a versioned record and the diff is signed with the change-ticket ID. Subsequent collections that match the new baseline don't fire alerts; collections that don't match either baseline fire as drift.
Drift detected on a device that was changed outside the platform — someone logged into the device locally, or via a non-Innovexus path — fires a drift alert immediately on the next poll. The alert includes the diff (what changed) and triggers the SOC investigation workflow. This is the primary detection mechanism for unauthorised change.
NERC CIP-010-3 R1 requires a documented baseline configuration, change documentation, and verification that changes don't introduce vulnerabilities. Innovexus produces a continuously updated, signed baseline; the change-ticket reference and the diff together satisfy R1.1–R1.5. SOC 2 CC8.1 (change management) is similar — the audit log shows who made the change, when, what changed, and that the baseline updated only after approval. ISO 27001 A.12.1.2 maps cleanly. We provide pre-built export templates for each framework.
Configs are stored encrypted at rest (AES-256) in the per-tenant pod's storage. Metadata (timestamps, device, hash, signing chain) is retained for the configured period — default 7 years. Full config bodies are retained for 90 days by default; longer retention is configurable up to the storage tier limit, or full configs can be exported to a customer-managed S3-compatible store for indefinite retention. The signing chain is preserved across export.
Provision a pod, point the collector at your fleet, baseline. Drift detection runs from minute one. Audit-ready exports for NERC CIP, SOC 2, and ISO 27001 are built in.