Compliance

Compliance checks the security settings of your Windows, Linux and macOS computers and gives each one a score. Every check shows what was found on the computer, what is expected, what the setting protects against and how to fix it, with ready-to-paste commands.

The checks are based on the DISA Security Technical Implementation Guides (STIGs), the US Department of Defense's public hardening standards for Windows 11, Windows Server, Red Hat Enterprise Linux and Ubuntu, and on the Microsoft security baselines. For Macs, the checks follow the NIST macOS Security Compliance Project (mSCP) and the DISA Apple macOS 15 STIG. Each check cites the rule it comes from, for example WN11-SO-000205 (V-253462), RHEL-09-255045 or mSCP os_sip_enable / APPL-15-005001, so you can look up the full guidance. The wording and the selection of checks are our own.

What is checked#

About 470 checks: 217 for Windows, 230 for Linux and 21 for macOS.

Windows (217)	Linux (230)
Password, lockout and Kerberos policy; Guest, built-in Administrator, automatic logon; local administrator password managed by LAPS	SSH server: root login, empty passwords, key exchange, ciphers and MACs, strict modes, idle timeout, X11 forwarding…
NTLM (v2 only, session security), LM hashes, WDigest, LSA protection, Credential Guard, memory integrity, cached logons, secure channel	Accounts and PAM: only root with UID 0, no empty passwords, no nullok, password length, complexity and hashing, lockout, idle shell timeout
User rights: debugging, acting as the OS, creating tokens, loading drivers, impersonation, backup/restore and more, and the deny logon rights for workstations, member servers and domain controllers	sudo: installed, no NOPASSWD or !authenticate, ticket timeout
Anonymous access, SMBv1, SMB signing, insecure guest logons, LLMNR, NetBIOS, source routing, ICMP redirects, LDAP signing, WinRM and Remote Desktop hardening	Permissions of account files and their backups, SSH host keys, cron, GRUB configuration, /var/log
UAC (all prompts and modes), AutoRun/AutoPlay, Windows Installer, SEHOP, SmartScreen, screen lock, Windows Hello and PIN rules, consumer features, Automatic Updates	Kernel hardening (ASLR, kernel pointers, ptrace, BPF, kexec, core dumps), kernel modules (USB storage, rare file systems and network protocols), mount options (nodev, nosuid, noexec)
Advanced audit policy: about 30 subcategories (logons, account and group changes, process creation with command lines, policy changes, removable storage, file shares…), PowerShell logging and transcription	Network: ICMP and source routing, redirects, reverse path filtering, IPv6 router advertisements and forwarding
Antivirus, firewall, BitLocker (and startup PIN length), Secure Boot, TPM, NTFS, supported Windows release, no Simple TCP/IP, SNMP or IIS on clients	Audit rules (accounts, sudoers, logins, privileged commands, mounts, modules, permission changes, deletions, program execution) and auditd settings for full disks and log rotation
Local accounts (unused, without a required password, passwords that never expire, on domain members), Telnet/TFTP clients, Fax, PNRP and SMBv1 features, Exploit Protection (system-wide, and per program on servers), virtualization-based security, Early Launch Antimalware, port proxies, smart card removal	Lockout (faillock), password history and hashing (also of stored passwords), primary groups, fail delay, inactive accounts, GDM automatic sign-in, locked GNOME settings, su restricted to wheel, sudo rules, unique user and group IDs, system accounts without a shell
Permissions of the system drive, Windows and Program Files folders, event log files, Event Viewer and HKLM	Kernel command line (audit, page poisoning, vsyscall, mitigations), core dumps, NFS and removable media mount options, permissions of commands, libraries and their folders, home folders and their groups, audit tools, rules and logs; files without an owner
Domain controllers: directory service auditing, who may change GPOs and OUs, auditing of key directory objects, krbtgt password age, unused and never-expiring domain accounts, LDAP signing, Kerberos policy, machine password resets, who may add computers or sign in remotely, NTDS and SYSVOL permissions, anonymous directory access, LDAP idle time	Services: no Telnet, rsh, TFTP, FTP or NIS servers, kdump, debug shell, Bluetooth; firewall, AppArmor/SELinux, file integrity (AIDE: rules, baseline database, reports), system logs and forwarding them (encrypted) to another system, crypto policy, time sync (chrony client only), package signatures (Red Hat keys, pacman), automatic updates, GNOME screen lock and automount

Some checks need a recent Census agent: Linux kernel modules, mount options, audit rules, sudo, journal and GNOME settings need 0.73.0 or later; Windows permissions, local accounts, features and Exploit Protection, and the Linux PAM, boot, file-system, package and audit-status checks need 0.74.0 or later; passwords that never expire, per-program Exploit Protection, the domain controller checks of directory permissions, auditing, krbtgt and unused domain accounts, and the Linux AIDE, log forwarding, chrony, package key, stored password, group and folder checks need 0.76.0 or later. With older agents they show as Unknown. Checks that need root or administrator rights show Unknown for scans without them. Some checks are deliberately less strict than the STIG where the STIG would raise alarms on almost every normal computer; their Expected text says so.

macOS (21): FileVault, System Integrity Protection, the signed system volume, secure boot (full security), Gatekeeper; application firewall and stealth mode; automatic login, guest account, password hints, root account; automatic checks/downloads, security responses and macOS updates; Remote Login (SSH), Screen Sharing, Remote Management, File Sharing, Remote Apple Events, Printer Sharing; time synchronization. Values are what the Mac actually does, whether set by hand or by an MDM profile. Mac results need the Census agent 0.37.0 or later (or an SSH scan as root); some checks (secure boot, Remote Management, time sync) need root.

The list is in the app under Compliance; click a check for its full description, fix and references. Turn off any check you don't want under Configuration › Vulnerabilities & compliance. For an organization-wide view of your security practices, built partly on these checks, see Audit evidence.

Results and score#

Each check has one of four results:

Result	Meaning
Pass	The setting is as expected
Fail	The setting is not as expected; the Found column shows what was found
Not applicable	The check doesn't apply to this computer, for example Remote Desktop checks when RDP is turned off, BitLocker on servers and virtual machines, Credential Guard on computers that aren't domain-joined, IP forwarding on Docker hosts, SSH checks when no SSH server is installed
Unknown	The setting couldn't be read (see below)

To avoid false alarms, checks look at the effective setting: when a Windows setting isn't configured by policy, it is evaluated at its documented Windows default (shown as not configured (Windows default: …)). For example, SMB signing counts as required on Windows 11 24H2 and Windows Server 2025, where that is the default.

The score is the share of passed checks, weighted by severity (high = 3, medium = 2, low = 1). Not applicable and unknown results don't count; accepted failures count as passed.

A few checks are deliberately a little more lenient than the STIG where Microsoft's own baseline differs, and say so in their Expected text (for example account lockout after 10 failed attempts instead of 3).

Unknown results#

The settings are read during each inventory:

• Census agent: runs with full rights and reads everything. Agents older than version 0.12 don't collect security settings yet: update them.
• WinRM scans: the scan account needs administrator rights to export the security and audit policy.
• SSH scans: reading the effective SSH server configuration and /etc/shadow needs root or passwordless sudo.

Computers that were last inventoried before the upgrade show all checks as unknown until their next inventory.

SSH server checks are not applicable when the SSH server is installed but neither enabled nor running (common on desktops, where openssh is installed for the ssh client), and are checked again as soon as it is turned on. On Arch-based systems where the server has never run, the agent still reads its configuration (it has no host keys yet, so a temporary one is used for the check).

Arch Linux and Arch-based distributions (EndeavourOS, CachyOS, Garuda, Manjaro…) are checked like other Linux distributions. Automatic updates are not applicable there, since Arch is meant to be updated by hand with pacman -Syu.

Pages#

• Compliance: the average score, how many computers are below 50%, high-severity failures, and every check with how many computers pass and fail. Filter by Windows/Linux/macOS, search by name or STIG ID, or show failing checks only. Export failed checks (CSV) lists every failed result.
• Check details: description, why it matters, how to fix it, references, and the result on every computer.
• Computers by score: lowest scores first.
• Compliance tab on each Windows, Linux or macOS asset: the score and every check grouped by category, failures first. Each check says what it protects against; failed ones have How to fix. Click a result tile (Failed, Passed…) to list only those checks (Fixed by Census lists the fixes Census pushed to that computer, with Undo); click it again or Show all checks to see all. After Rescan the tab updates by itself once the new results are in.

Fix commands#

Most checks come with commands you can paste into a terminal (Linux, macOS) or an administrator PowerShell window (Windows), with a Copy button. Where distributions differ, there are boxes for Debian/Ubuntu, Fedora, RHEL/Rocky/Alma and Arch-based systems (Arch, CachyOS, Manjaro, EndeavourOS); an asset's Compliance tab shows its own distribution's first and folds the others away. Other distributions (openSUSE, Alpine…) get the generic commands only. Lines starting with # explain the step; replace NAME with the account the check found.

• Linux SSH settings go into /etc/ssh/sshd_config.d/01-hardening.conf (read first, so it wins over other files), checked with sshd -t before the SSH service reloads. Keep your session open until a new login works.
• Linux kernel settings go into /etc/sysctl.d/zz-hardening.conf (read last, so it wins) and apply at once with sysctl --system.
• Windows commands change the computer itself. In a domain, set the Group Policy shown above instead: a policy overrides local changes.
• Some fixes have no safe one-line command (BitLocker, Credential Guard, user rights, the Debian/Ubuntu account lockout PAM lines); they are described in words.

The checks are evaluated again at the computer's next inventory (the Census agent reports every few hours; Rescan on the asset page does it now).

Turning checks off#

Administrators can turn off compliance for all Windows, all Linux or all macOS computers, or turn off individual checks, under Configuration › Vulnerabilities & compliance, or with Turn this check off on a check's page. A turned-off check shows as Not applicable with the note Turned off in Configuration and doesn't count in scores; computers of a turned-off platform aren't scored at all. Results update within a minute. To exempt only some computers from a check, accept the risk instead (below).

Accepting a risk#

When a setting can't be changed (a legacy application needs NTLMv1, a kiosk needs automatic logon), click Accept risk on the check or on one computer's result, and choose:

• Only this computer, computers in a group (static or dynamic) or all computers;
• a reason (required) and an optional expiry date.

Accepted failures count as passed in the score and are shown as Accepted. Compliance › Exceptions lists every exception with who created it and why. Expired exceptions stop applying automatically and can be deleted under Cleanup & retention.

Reports and dashboard#

• Reports in the Compliance category: Compliance score per asset and Failed high-severity configuration checks. Like any report they can be emailed on a schedule (see Alerts).
• The dashboard's Compliance panel shows the average score, high-severity failures and how computers are spread across score ranges.

Who can see it#

Administrators and custom roles with the Compliance permission (see Configuration), which also allows accepting risks.

Pushing a fix#

Many checks can be fixed from Census: open the check and click Fix on computers… (all computers where it fails), or click Fix next to a failed check on an asset's Compliance tab. Census shows the commands it will run and on which computers (Linux computers get the commands for their distribution), then runs them as SYSTEM / root through the Census agent, WinRM or SSH, and scans the computers again afterwards. Each push appears under Deployment with the output of every computer.

Only checks whose fix needs nothing typed in can be pushed; fixes that need a name, a password, recovery mode or a decision only show the commands to copy.

Try a fix on one or two computers first. A security setting that is right for most computers can stop something a particular computer is used for. Push a fix to a few computers, check that everything people need still works, then push it to the rest. A Group Policy or MDM setting is often the better way for many computers anyway.

Fixes that can stop things on the computers. Some fixes switch off something older devices, programs or people may still rely on: NTLMv1 and SMB 1 for old copiers and NAS boxes, Bluetooth, Wi-Fi, USB devices plugged in later, port forwarding rules, automatic sign-in on kiosks, servers such as FTP or TFTP. Their check pages and push dialogs show a red warning that says what can stop, and you must tick a box to confirm.

Fixes Census doesn't push. A few fixes would be hard to take back without someone at the computer, so Census only shows their commands to copy, or refuses them where they would do harm:

• Settings that Windows stores in the firmware (LSA protection and memory integrity with UEFI lock): Census sets them without the lock, and pushes LSA protection only to Windows 11 22H2, Windows Server 2025 and later.
• SELinux on a computer where it is turned off completely (switching it on needs a relabel and a restart).
• Disabling the built-in Administrator on a computer without another enabled administrator account.
• Turning Wi-Fi off on a computer without an active wired connection.
• Dropping to single-user mode when the audit disk fills up, turning FileVault on, replacing Sendmail with Postfix, and renaming the built-in Administrator (needs a name).

Fixes that can break Census. A few fixes can stop Census itself from reaching or managing the computer, for example turning off root sign-in over SSH when Census scans with a root account, denying network sign-in to local accounts when Census uses Windows LAPS or a local administrator, or mounting /tmp with noexec, which stops deployments. These show a red warning that explains what will stop working, and you must tick a box to confirm. Switch those computers to the Census agent, or to a different account, first.

When a Group Policy or MDM profile sets the same setting, it overrides the change at its next refresh: change the policy instead.

Undoing a pushed fix#

If a fix breaks something, you can undo it. Before the fix runs, Census saves on each computer everything the fix is about to change: the files it edits (with their owner and permissions), registry values, audit and account policies, services, kernel settings, mount options, installed packages, Windows features. After the fix runs (also when it fails), Census saves them again.

Pushed fixes are listed under Fixes pushed by Census, on the check's page (one row per computer) and on each computer's Compliance tab behind the Fixed by Census tile (one row per check; the tile shows how many fixes were pushed). Click Undo next to a computer: Census runs the undo on that computer through the agent, WinRM or SSH, the same way as the fix, and then scans it again. The undo's output is under details, and under Deployment.

The undo puts back only what is still the way the fix left it:

• Settings changed after the fix are left as they are, because an administrator, a Group Policy or a later fix changed them since. The undo's output lists them under Left as they are.
• Lines the fix added to a file come out even if the file changed later. For example, undoing one kernel setting leaves the settings later fixes added to the same file in place.
• Packages the fix installed are removed again, and packages it removed are installed again from the computer's configured repositories. sudo is never removed.
• A few changes can't be put back. Census lists them before you push the fix and again when you undo it: Apple Remote Desktop turned off, the root account disabled on a Mac, the AIDE database created, a package signing key imported.

The saved settings stay on the computer until an undo has put everything back. On Windows they are in C:\ProgramData\StewardCensus\fix-undo (readable by administrators only); on Linux and macOS they are in /var/lib/census-fix-undo (readable by root only). Fixes pushed with Census versions before this feature can't be undone from Census: use the commands on the check's page instead.

If the fix stopped Census from reaching the computer (see Fixes that can break Census above), the undo can't reach it either, except through the Census agent.

Pushing or undoing a fix needs the Compliance permission plus Console or Deployment.