Configuration Compliance in Unimus 2.8.0

Like it or not, IT infrastructure and its underlying networks exist in constant flux.

What starts as a clean, well-planned environment can - if left unchecked - slowly slip into something… less predictable. Device configurations drift, policies go stale, a temporary firewall rule added during troubleshooting might linger long after it’s needed, and the gap between “how things should be” and “how things actually are” quietly widens.

And that’s exactly where Compliance steps in to restore order.

Why compliance matters

Compliance isn’t an unnecessary administrative burden. It’s about knowing exactly where your network stands.

A network that is compliant to configuration rules & best practices delivers real, practical benefits:

• Configs stay consistent
• Policies remain enforced
• Troubleshooting is simpler and therefore faster
• Audit requests are manageable and don’t turn into a fire drill
• Attackers have fewer opportunities to exploit

And with standards like PCI DSS, ISO/IEC 27001 and the NIS2 Directive, having a controlled and monitored configuration baseline is no longer optional - it’s simply expected.

For all the reasons outlined above, Unimus 2.8.0 introduces the new Compliance engine — a highly requested addition to device configuration management. This module provides a structured way to automatically validate your network’s compliance at scale, whether you’re checking device configurations or monitoring live runtime state. With it, you can keep device configuration drift under control and ensure your network operates as intended. Read on for the full details.

How the new Unimus Compliance module works

Let's dive into the details. The new Compliance engine follows a preset-based structure, similar in spirit to Mass Config Push. Each Compliance preset defines a set of policies (rules and conditions), that Unimus checks against a chosen dataset and on specific devices.

Each Compliance preset is built from three parts: Source, Targets and Rules. Let's break down each of them below.

Preset sources

Source is the actual data you want the Compliance engine to validate.

You can choose from multiple source types:

Last Backup - the preset validates the most recent configuration backup (the current config running on the device).

Config Search result - the preset validates the latest configs of devices returned by a Saved Search.

Mass Config Push result - the preset validates device output produced by running an MCP preset.

Next, let’s look at how targets are determined.

Preset targets

Compliance targets are the devices being validated. Your selected data source affects how the targets are determined.

For presets where the Source type is Last Backup, you choose the targets directly - you can pick devices one by one, filter them by vendor or device type, or simply select by Tag.

When the preset source is set to Config Search result, the devices returned by a selected Saved Search become the targets. Only devices whose configurations match the search criteria of the Saved search are included. This is useful when you want to narrow the scope to devices that contain a specific configuration pattern - for example, to run checks only on devices that still use an old SNMP community, contain a deprecated ACL, or have a specific banner present in their backups.

When the preset source is a  Mass Config Push result, the targets are simply the devices targeted in that MCP preset.

With the sources and targets settled, we can turn to the heart of every Compliance preset - the rules.

Preset rules

Finally, rules define what the Compliance engine should look for in the chosen dataset (source). This is where the engine becomes really flexible. Each preset can include one or more rules, and each rule can include one or more conditions. You can create your own  compliance policies by defining conditions using:

• simple text-matching
• regular expression matching
• line-anchored checks
• combination of multiple conditions with AND/OR logic

Whether you need to enforce a specific configuration line, detect an insecure service, or confirm that an operational state is correct, these Compliance preset building blocks let you express the logic you need.

Continue reading to see how the new Compliance feature can fit into your workflow, with examples highlighting its flexibility and capabilities.

Examples and use cases

1. Defining a golden configuration

Let’s start with the most straightforward example.

Many teams maintain an internal “golden config” - a baseline device setup reflecting their operational and security standards. With Unimus, you can now define that baseline and have the system check against it.

Simply paste your expected configuration snippets into a Compliance condition, set the preset source to Last Backup, and define your target devices. Your condition might check for the correct firmware version, approved AAA servers, proper NTP servers, and logging. It could also enforce security hardening measures such as restricted SNMPv2 use, disabled insecure protocols like Telnet, removal of legacy ciphers, and strict password or authentication policies.

And with automatic execution enabled, the Compliance engine runs whenever a new configuration backup is generated for a targeted device.

With the preset in place, Unimus will continually review your latest configuration backups and flag any devices that drift from the baseline. No more combing through massive configs across hundreds of devices — the Compliance engine takes over, quietly keeping everything in check.

2. Beyond the golden config: Enforcing precise network policies

In addition to golden configuration presets, the Compliance engine lets you define flexible conditions using regular expressions, giving precise control over which configuration elements are allowed or disallowed on each device.

On the access layer of your network, you can enforce protections such as BPDU Guard or Root Guard for STP, making sure edge ports behave exactly as they should.

Moving up to the distribution and core layers, the engine can verify routing protocol security: OSPF or EIGRP authentication, proper route filtering, or that your IPv4 and IPv6 firewall states are in the expected shape.

At the edge or peering layer, you can validate BGP hardening — passwords, TTL security, session policies, and other controls that keep your network’s perimeter well-defended.

In this way, multiple checks can be combined for each device role, ensuring every part of your network aligns precisely with your policies.

3. Runtime compliance: validating your live network state

Compliance goes beyond just validating device configurations!

A valid configuration doesn’t automatically guarantee smooth operations. Configurations show how things should be — runtime data shows how things actually are. For example, your OSPF configuration may be correct, but how do you know your OSPF peers are actually up? Reviewing your latest configuration backups won’t help you here.

That's why Compliance Reporting also lets you validate live device output gathered through Mass Config Push / Pull, ensuring you have a precise understanding of your network’s current state.

Start by creating and scheduling a Mass Config Push preset targeting the devices whose runtime state you want to inspect. Even tho the feature in Unimus is called "Mass Config Push", we will use it to Pull data from devices in this case. The MCP preset should include the appropriate show commands that query the devices’ operating state.

Next, create a Compliance preset, enable Automatic execution, and select “Mass Config Push result” as its source, targeting your preconfigured MCP preset. Then define the rules and conditions that will evaluate the collected device output using text or regex matching. After each MCP run, the engine analyzes the latest runtime output from your devices and checks it against your Compliance rules.

This gives you visibility into the living, breathing state of your network, and because the system lets you define granular, fine-tuned conditions, the possibilities are remarkably rich — limited mainly by what you choose to monitor and the information your devices can provide through their CLI.

You can see whether your routing is healthy, BGP neighbors have dropped, OSPF is stuck in INIT, or EIGRP peers have gone missing. You can keep an eye on interface health as well: ports slipping into err-disabled, speed and duplex mismatches, rising error counters, or even devices running hot and experiencing high CPU utilization. The engine can also surface stack member inconsistencies in high-availability setups, failover activity, or sync issues.

And that’s just scratching the surface — the range of runtime checks you can create is virtually limitless, so explore them freely and tailor them to your specific needs.

Tracking compliance at a glance

Once your Compliance rules are set up and presets executed, how do you track the compliance state across hundreds of devices and multiple policies? You don’t have to dig through menus — a quick glance at the Device List shows whether everything is as it should be. For each device, Unimus displays a small compliance indicator in the Compliance column:

Green – device is fully compliant

Red – device is non-compliant

Yellow – source dataset is missing or invalid

Grey – device is unmanaged or hasn’t been checked yet

You can see per-preset Compliance state on the Compliance Home page.

But if you want to see the entire "battlefield" on one page, Unimus has you covered with the Compliance Matrix: every device laid out against every preset, making patterns and outliers jump out instantly. It’s especially useful when validating large-scale changes.

If you need more than a bird’s-eye view, you can drill down into the evaluation details. The Compliance engine validates compliance on multiple levels, letting you see exactly which condition caused a device to fail. For a deeper dive, check out our detailed wiki article.

What’s next?

Compliance Reporting in 2.8.0 lays the groundwork for broader compliance automation. In upcoming updates, you can expect Compliance notifications via email, Pushover, and Slack, as well as export options for HTML and CSV formats to support reporting and audits. We’re also improving the ability to search through rules and conditions, making it easier to manage complex presets.

As these features roll out, Compliance will continue to evolve, becoming an integral part of your everyday operational workflow.

Final words

Thanks for reading all the way through!

We hope this article has given you a clear overview of the robust and flexible Compliance Reporting module in Unimus 2.8.0, and shown how it helps keep your network aligned with both industry standards and your own company policies.

For a full, wiki-style documentation of the feature, check out our wiki article.

The Compliance Module is available in the Advanced Unimus tier as part of our new licensing model.

Lastly, if you encounter anything unexpected or have feedback, feel free to reach out via our forums or the usual support channels.

Until next time — stay on top of your networks, and keep your devices compliant.