Auditing Operator Activity

The Manager writes an audit entry for every gate result and every state change: an operator signing in, a policy or setting changing, a backup starting or failing, a restore being approved, a role changing hands. The audit trail shows who did what, from where, and on whose authority. You read it on the Audit Trail screen, which every role can see, or with cdr audit list, and you can export it as CSV, JSON, HTML, or PDF.

For a description of the screen, see Audit Trail.

What is audited

Operators and sign-in—Setup of the Manager and the break-glass confirmation, sign-ins, failed sign-ins, sign-outs, lockouts and unlocks, accounts created, changed, disabled, and enabled, password resets and changes, and multi-factor authentication being turned on, turned off, or reset, with each recovery code used.
Configuration—Every settings change, retention changes separately, policy changes, the recovery passphrase being set, and changes to the Manager CA, including a re-key.
Agents—Enrollment and re-enrollment, certificate renewal, refused messages, console-started deployments, and restart and uninstall requests made through the Manager.
Backups and the vault—Each backup job's creation, completion, failure, interruption by a DC agent restart, and cancellation, refused backups, retention sweeps and deletions, failed verifications, and the hourly check of backups that did not reach the vault. The storage agent's findings are recorded too, each once: Unexpected use of the staging share (staging.smb.unexpected), Changes detected in vault content (vault.change.detected), a change to a committed backup outside retention, recorded once per backup version; Vault changes reviewed (vault.change.reviewed), a review of such a change with its note; and Vault change watch lost its place (vault.watch.position-lost), a vault watch that restarted without its saved position, so changes in that window went unwatched.
Configuration backups—Each attempt to send a configuration backup to a storage machine and how it ended (manager.config-backup.stored, manager.config-backup.failed, manager.config-backup.refused), and each import with CygnaDR.Manager.exe bundle import (manager.config-backup.imported), which names the Windows account that ran it.
Support packages—Each support package created (from the console, cdr, or the Manager's local support package command), each download, and each removal from the Manager (Support package created, Support package downloaded, Support package deleted).
Alert email—Each alert email sent, with how many objects it listed as raised, cleared, and still raised (Alert email sent, alert.email.sent); a failure to send, when it starts and when its reason changes (Alert email not sent, alert.email.not-sent); and each test email, with the operator who asked (Test alert email requested, alert.email.test).
The audit trail itself—Each export of the audit trail (Audit trail exported).
Topology—Domain controllers discovered, objects recorded as removed or held for review, exclusions added and cleared, and operations master roles moving.
Recovery—Every restore run and recovery plan action: planned, approved, approval withdrawn, executed, cancelled, discarded, abandoned, and its outcome, and for plans, each point-of-no-return acknowledgment, attestation, rejection, and overridden wait. Vault read leases issued and revoked for each restore are recorded too, and for a DC state recovery, each krbtgt reset.

Domain credentials given to a recovery plan or to a DC state recovery's krbtgt reset, and passwords used for push installation, are never recorded. Changes that cdr agent deploy and cdr cleanup make in the directory use your own Windows credential and are recorded in the domain controller's own security log.

What an entry records

Field	Description
When	When the entry was recorded. The detail sheet shows it as Recorded (local) and Recorded (UTC).
Actor	Who caused it. For an operator's action this is the operator's username. Work the product does on its own is recorded as System, Manager, or Storage agent. A failed sign-in is recorded as Unauthenticated caller, because nobody had signed in.
Action	What happened, as a label and an action code such as `restore.run.approved`. A code the console has no label for is shown as the code.
Subject	What it happened to, usually a machine, domain, or object name.
Fields	The entry's detail. Every entry caused by a network request, from the console, `cdr`, or an agent, carries `remoteAddress`, the address the request came from, and `remoteHost`, the name reverse DNS gave for that address when one was found. Rely on the address: the host name is only as trustworthy as the reverse DNS zone. An entry with neither field came from the Manager's own scheduled work, not from the network.

An entry written by the Manager's local maintenance commands, such as CygnaDR.Manager.exe ca recover, names the Windows account that ran the command.

Finding entries

On the Audit Trail screen, the filters are applied by the Manager:

Actor—One actor, such as an operator's username.
Action—One action, listed with its label and code.
Subject contains—Part of a machine or object name.
From and To—A date range.

The Manager returns the newest 200 matching entries and the total count. The search box narrows the entries already returned; to reach older entries, narrow the filters. Select an entry to open its detail sheet, which shows every field and the detail exactly as stored.

From a script, cdr audit list takes the same filters:

cdr audit list --actor jsmith --from 2026-10-01 --detail
cdr audit list --action restore.run.approved --json

--from and --to take UTC times, as yyyy-MM-dd or a full timestamp. --actors lists every actor and action code in the trail. See Alert, Audit, and Report Commands.

Entries worth reviewing regularly

Action (code)	Why
Operator created (`operator.created`), Operator roles or name changed (`operator.updated`), `operator.removed`, `operator.restored`, `operator.mfa.reset`	Who was given which capabilities, who was removed or restored, whose MFA was reset, and by whom. A removal records the roles the account held; a restore records the roles it was given.
Sign-in failed (`operator.signin.failed`), Account locked after failed sign-ins (`operator.locked`), `operator.signin.mfa-challenged`, `operator.mfa.locked`	Password and MFA code guessing, and from which address. Each refused sign-in is recorded with its reason, such as a wrong password, a locked or disabled account, or too many failures from the address. A username that no account holds is recorded as `(unknown username)` with a fingerprint, never as typed, because it may be a password. A code request with no sign-in after it, or a lock on MFA codes, means someone has the operator's password.
Signed in (`operator.signin`) by `breakglass`	The break-glass account should be used only in an emergency.
Retention changed (`config.retention-changed`), Configuration changed (`config.changed`)	Changes that can reduce what is kept.
Restore approved (`restore.run.approved`), Restore execution requested (`restore.run.execute-requested`)	Who approved and who executed each restore.
`restore.krbtgt.reset-requested`, `restore.krbtgt.reset`, `restore.krbtgt.reset-failed`	Who started a DC state recovery's `krbtgt` reset again, and each reset the domain controller's agent applied or failed. The credentials are never recorded.
`manager.config-backup.failed`, `manager.config-backup.refused`, `manager.config-backup.imported`	A configuration backup did not reach a storage machine, or a Manager was rebuilt from one.
`manager.ca.rekeyed`, `manager.ca.recovered`	The Manager's CA was replaced or recovered.
Storage machine replaced (`storage.replaced`), Second storage agent enrolled as a candidate (`storage.candidate-enrolled`), and the `change-request.*` entries	Who replaced the storage machine and how many restore points it ended, who asked for and decided each request, and when a storage agent enrolled that nobody may have meant to install.
Isolated Recovery Host approved (`recovery-host.approved`), `recovery-host.draining`, `recovery-host.undrained`	Who allowed a host to read backups for test restores, and who took one out of use.

For every multi-factor authentication action, see Multi-Factor Authentication.

Exporting entries

To give an auditor a record, or to archive the trail before you shorten its retention, export it. Select Export on the Audit Trail screen, or run cdr audit export. Exporting needs the audit.view capability, which every role includes.

What is exported—Every entry that matches the filters and, in the console, the search box, across the whole trail. The 200-entry limit of the screen does not apply.
Formats—CSV and JSON hold up to 100,000 entries; HTML and PDF, documents for a person to read, hold up to 5,000. When more entries match, the export is refused with the reason, never cut short. Narrow the dates or the filter, or export in parts.
Wording and times—A console export uses the console's wording for actors and actions, with the codes beside them, and gives times in UTC and in your browser's time zone. cdr audit export writes the codes, and times in UTC and the time zone of the machine it runs on.
Spreadsheet safety—In a CSV file, a value that starts with =, +, -, @, a tab, or a carriage return gets a leading apostrophe, so a spreadsheet does not run it as a formula. This matters because the subject of a failed sign-in is whatever an unauthenticated caller typed.
File name—cygnadr-audit-<yyyyMMdd-HHmmss>.<format>, from the UTC time of the export.
Recorded—Each export is itself an audit entry, Audit trail exported (audit.exported), written before the data leaves the Manager. Its subject is the file name, and its fields record the format, the number of entries, the filter, and the search.

For the formats and the export menu, see Audit Trail.

Retention of the audit trail

By default the audit trail is kept forever. The Audit trail setting under Database retention on the Configuration screen sets how many days entries are kept; 0 means forever. Shortening it deletes entries for good, including entries that record changes to settings, so saving it needs typed confirmation. Set a window only where your own data-protection rules require one. See Settings Reference.

The audit trail lives in the Manager database. If the Manager is restored from a backup or a database snapshot, entries written after that point are not in the restored trail. See Recovering the Manager.