# Compliance rules

Check device configurations against the 10 built-in compliance rules and your own text checks, read the results per rule and per device, and fix what fails.

Compliance rules check what your devices are configured to do, such as whether Telnet is off or logs go to a remote server. This page lists the built-in rules, shows how to add your own checks, and explains how to read the results.

## How compliance works

Open **Network › Config Mgmt › Compliance**. The page evaluates every managed device each time it loads, and again when you select **re-evaluate**. Choose what to evaluate:

* **Running backup** (the default): the configuration from each device's latest backup. This answers whether the device is compliant now.
* **Intended configuration**: the configuration you declared. This answers whether your intent is compliant.

A check either passes, fails, or is **Not evaluated** when Tracix doesn't have the evidence to decide, for example when a device has no backup yet. A check that isn't evaluated is never counted as a pass or a failure, and scores leave it out. The **Fleet report** under **Reports** shows the running compliance score next to backup and sync status.

Each rule carries a control reference, such as CIS 2.1, and you can filter the page by control family. The references are informational: they point to the kind of control a rule supports, not to a certification.

## Built-in rules

Ten rules are built in. They read normalized configuration fields, so for a backup Tracix keeps only in the device's native format they show **Not evaluated**; cover those devices with a [text check](#add-a-text-check).

| Rule                            | Severity | Fails when                                                | Control reference     |
| ------------------------------- | -------- | --------------------------------------------------------- | --------------------- |
| Telnet disabled                 | Critical | Telnet is enabled for management access                   | CIS 2.1               |
| SSH version 2                   | High     | SSH version 2 isn't enforced                              | NIST AC-17            |
| Centralized AAA                 | High     | No TACACS+ or RADIUS login method is configured           | NIST IA-2             |
| No default SNMP community       | High     | The `public` or `private` community is in use             | PCI 2.1               |
| No cleartext stored credentials | High     | The configuration contains a cleartext or type 0 password | NIST IA-5             |
| NTP configured                  | Medium   | No NTP server is configured                               | CIS 6.1               |
| Remote logging configured       | Medium   | No remote syslog server is configured                     | PCI 10.5              |
| Redundant NTP servers           | Low      | Fewer than two NTP servers are configured                 | CIS 6.1               |
| Login banner present            | Low      | No login or MOTD banner is configured                     | DISA STIG NET-NAC-009 |
| Management interface present    | Low      | No management interface is defined                        | CIS 3.4               |

Passing **No cleartext stored credentials** means Tracix found no cleartext password; it doesn't prove that the stored secrets use strong hashing. Passing **Management interface present** doesn't prove the interface is protected; review its access policy separately.

## Add a text check

Text checks look for a string or pattern anywhere in the configuration, so they work on every backup, including native ones.

**1. Open the editor**

On **Compliance**, under **Required and forbidden configuration checks**, select **Add text check**.

**2. Describe the check**

Enter a **Check name** and choose the **Match type**: **Plain text (case-insensitive)** or **Regular expression (advanced)**. Under **Applies to**, keep **All platforms** or pick one platform, and choose a **Severity**.

**3. Set the pattern**

Enter the text or expression, for example `service password-encryption`. The check fails when the pattern is missing. To fail when the pattern is present instead, select **Fail when the pattern is present (otherwise require it)**.

**4. Test it and save**

Enter **Remediation guidance** for whoever fixes a failure. Paste a **Sample configuration** and select **Test sample** to see whether it passes, then select **Save and evaluate**.

Saved checks are listed in the editor, where you can remove them, and they appear with the built-in rules. Brain can also create rules that check whether a section is present or absent, or whether a field has a given value. Adding and removing checks needs write access to configuration management.

## Read the results

* **Rules** lists each rule with its severity and how many devices pass it.
* **Devices** lists each device with its failing checks, its score and its last backup.

Select a device to see its findings. **Declared intent versus running backup** compares the device's latest backup with its intended configuration, requirement by requirement. **Independent configuration rules** shows every rule's result, the reason for each failure, and the remediation guidance.

## Fix what fails

Most built-in rules have a matching building block in **Intent & templates**. Select **Create baseline for this requirement** under a rule, or tick several rules and select **Compose a fleet baseline from selected checks**. Apply the baseline to the failing devices and deploy it through a change request; the next backup shows whether the fix landed. See [Drafts and change requests](https://tracix.io/docs/network/ncm/change-requests).

## Next steps

- [Drafts and change requests](https://tracix.io/docs/network/ncm/change-requests): Deploy the fix through a reviewed change

- [Backups and drift](https://tracix.io/docs/network/ncm/backups): Keep backups fresh so results stay current

- [Supported platforms](https://tracix.io/docs/network/platforms): What each OS family supports