By David,
Someone added a user to the admin group last Tuesday. Someone drained a host pool at 4:55 on a Friday. Someone opened a remote session on the finance director's laptop. When an auditor, a customer or your own incident review asks who did it, you need an answer you can show them, not a guess pieced together from three portals.
Atlas AVD keeps that answer for you, every day. Each action an administrator takes, each change Atlas makes on its own schedule, each sign-in and each remote session lands in one audit trail inside your own Azure tenant. Nobody can quietly edit it afterwards.
This article walks through what Atlas records, where you read it, and how it lines up with the audit requirements in NIST SP 800-171 and CMMC.
The short version: open Security → Audit to see one timeline of every user action and infrastructure change in the tenant, live. Each entry carries who, what, when, where from, and a correlation ID. Configuration changes keep their before and after values. Atlas Reach records every remote session, and every action inside it is audited. The database rejects edits and deletes to audit records. You can export any view as CSV, Excel or PDF, and the export is itself on the record.
What "every action, every click" means in Atlas
"Every click" should mean something specific, so here is exactly what Atlas records and where you find it.
| Where the activity happens | What Atlas records | Where you read it |
|---|---|---|
| The Atlas console | Every sign-in and sign-out, every page an administrator opens, and every change they make, with the before and after state | Security → Audit |
| Your AVD environment | Every change Atlas makes for you: scaling, provisioning, drain, image builds, scripts, policy, recovery. Each one is attributed to the person or the named automation that made it | Security → Audit and TimeVault™ |
| Remote support with Atlas Reach | A recording of the whole remote session, plus an audit entry for each action inside it: consent, clipboard, file transfers, key sequences, scripts, power actions | The device's Audit tab and its recordings |
| Your users' AVD sessions | A timeline of each session: sign-in, FSLogix, network, broker and Atlas events next to the host's metrics. Events and metrics, not the screen | Session Replay |
| Microsoft Entra ID | Sign-in logs and directory audits, kept for a year even though Microsoft Graph only keeps 7 days on free and 30 days on P1 and P2 | The user's detail page |
In a remote session, every click really is on the record, because the session is recorded. In the Atlas console, Atlas records actions and pages rather than mouse movements or keystrokes. Each change you make, and each page you open to look at something, appears in the audit trail.
If it changed your environment, touched a user's device or opened a page of the console, it's on the record, with a name, a time and a correlation ID.
One timeline: the Audit page
Everything above flows into a single page. In the Atlas console, open Security → Audit. The page describes itself in one line: "A unified, chronological record of every user action and infrastructure change in this tenant."
What you can do from it:
- Watch it live. A Live badge shows the page is receiving new entries in real time, so you can watch a change happen while a colleague makes it.
- See both sides in one list. User Activity (sign-ins, sign-outs and pages opened) and Infrastructure (changes to host pools, VMs, users, policy, apps and the rest) are merged into one chronological list. Filter by source to see one side.
- Find anything fast. One search box covers user, email, action, resource and correlation ID. Narrow further by action, severity, resource type, user email and date, using Last 24 hours, Last 7 days, Last 30 days or a Custom range. Each filter shows as a chip you can remove, and the filters stay in the page address, so you can send a colleague the exact view you're looking at.
- Read the shape of the period at a glance. Four tiles summarise what you've loaded: Total audit events, Unique users, Action types and Resources, each with a trend line, the most active user and the most common action. A severity bar doubles as a filter: click Warning to see only warnings.
- Pivot from any row. From a row's menu, filter to that user, that action or that resource type, or open the user's profile.
What each record carries
An audit entry is only useful if it answers the questions someone will ask about it. Every Atlas entry records:
| Field | What it tells you |
|---|---|
| Timestamp | When it happened |
| User | Who did it, by name and email. Automation is named too, so a change made by the scheduler or by autoscale is never anonymous |
| Action | What they did, from one controlled vocabulary of more than a thousand action types |
| Resource | What it was done to: the host pool, VM, user, setting, credential or device |
| Severity | Debug, Info, Notice, Warning, Error or Critical |
| Before state / After state | For changes, the values before and after |
| IP address and user agent | Where the request came from |
| Correlation ID | Ties every entry produced by one request together, with a one-click copy |
That correlation ID is what turns a list into an investigation. When one action in the console produces several audit entries, they all carry the same ID, so you can search for it and see the whole chain in order.
Changes, with the before and after
"Someone changed the autoscale schedule" isn't much use on its own. Atlas records what the schedule was and what it became. Open any change entry and expand Before state and After state to compare the two, or View raw for the full metadata.
Configuration changes work the same way. Every setting you change in Atlas is recorded as its own entry with the old and new value. Values that are secrets, such as passwords, are stored as [REDACTED], so the audit trail proves that a credential changed without becoming a place where credentials can leak.
Sign-ins, failed sign-ins and permission denials
Successful sign-ins and sign-outs appear on the Audit page under User Activity. Failures are recorded too:
- Failed and blocked sign-ins are recorded, including replayed or mismatched sign-in attempts.
- Every permission denial is recorded. When someone tries something their role doesn't allow, Atlas records the attempt as a warning with the path and the source IP.
- Probing raises an alarm. Five or more denials or failed sign-ins from one person within ten minutes raises a critical "Privilege probing detected" alert.
Every click in a remote session: Atlas Reach
Atlas Reach is the remote view and control built into the Atlas endpoint agent. Remote access to a user's device is exactly the activity that needs the strongest evidence, so it gets the deepest audit coverage in the product.
- Sessions are recorded. Session recording is on by default on Windows, macOS and Linux. The relay that carries the session writes the recording, so it doesn't depend on the technician's machine.
- Every action inside the session is audited. Each step is its own audit entry: starting the session, the user's consent, view-only or full control, handing the session to a colleague, ending it, reading or setting the clipboard, uploading or downloading a file, sending a key sequence, running a script or a toolbox action, and power actions.
- Consent follows your policy. A scope's consent policy decides whether the signed-in user is asked before anyone sees their screen.
- Watching a recording needs the audit permission. Recordings are part of the audit trail, so replaying one needs the audit permission as well as Atlas Reach access. With end-to-end encryption on, playing a recording means unwrapping its key from your own Azure Key Vault, and that unwrap is audited as well.
- Retention is yours to set. The Recording Retention setting decides how long finished recordings are kept, with a default of 30 days. A change applies to recordings already stored, not just new ones.
Every Atlas Reach action against a device also appears on that device's Audit tab, so the full history of who touched one machine is on one page. Inside an Atlas Reach Windows device tours the rest of that page.
Every AVD session, replayable: Session Replay
When a user reports that "the desktop froze around two", the question is what happened in their session. Session Replay rebuilds any AVD session as a timeline you can scrub through: its connects, disconnects, reconnects and sign-out, with the session host's CPU, memory, disk queue and round-trip time on the same clock. It records events and metrics, not the user's screen.
Looking at a user's session is itself a sensitive act, so Atlas records who opened which replay. When an administrator acts on a live session, by shadowing it, sending a message or disconnecting the user, that action is audited too.
Records that can't be quietly rewritten
An audit trail is only evidence if the people it records can't edit it. Atlas protects its audit records at the database level, not just in the interface:
- Append-only by design. The audit tables reject any attempt to update or delete an entry, whoever is signed in. Only Atlas's own background processes can remove records, under a dedicated database role: the scheduled retention sweep, a data-erasure request, and removing a tenant entirely.
- The protection checks itself. It's installed when a tenant is created and re-applied every time Atlas starts, so it can't drift away unnoticed.
- Secrets never reach the log. Passwords, tokens and keys are redacted before an entry is stored.
- Exports are on the record. Every audit export is itself an audit entry, with the format, the row count and the filters that were applied.
- Privacy requests are handled cleanly. When a person's data is erased on request, their entries stay in the trail and the history stays intact, but the name, email and IP address are replaced with pseudonyms. The row shows (User data removed).
- Each tenant's trail is its own. Each tenant's audit records live in that tenant's own database, inside your Azure tenant. See why Atlas AVD runs inside your Azure tenant.
Getting the evidence out
Auditors rarely want a login. They want a file. From the Audit page, Export gives you CSV, Excel or PDF of the current view, or of the rows you select.
- Exports include the timestamp, source, user, email, action, resource type, resource, details, IP address, correlation ID, severity and duration.
- PDF exports carry your branding, so an MSP can hand a client an audit report under its own name. A PDF is capped at 5,000 rows. Use CSV or Excel for anything larger.
- Exports are protected against spreadsheet formula injection, so a malicious value in a resource name can't run as a formula when the auditor opens the file.
For your AVD platform logs, Log Analytics Integration turns on each host pool's AVD diagnostics and sends them to your own Log Analytics workspace. From there you can query them with KQL, view them in AVD Insights, or bring them into Microsoft Sentinel.
How it maps to NIST SP 800-171 and CMMC
CMMC Level 2 takes its audit and accountability practices from NIST SP 800-171 Rev. 2, section 3.3. No product makes an organization compliant on its own. Your assessor looks at your policies, your processes and how you run them. But each requirement needs evidence, and Atlas produces it:
| Requirement | What Atlas gives you as evidence |
|---|---|
| 3.3.1 Create and retain audit logs | Console actions, infrastructure changes, sign-ins and remote sessions recorded automatically, every day. Infrastructure changes are kept for a year |
| 3.3.2 Trace actions to individual users | Every entry names a person, or the specific automation that acted, with email, IP address and user agent |
| 3.3.5 Correlate review, analysis and reporting | Correlation IDs that link every operation one request produced, plus filters that pivot across user, action and resource |
| 3.3.6 Audit record reduction and report generation | Search, filters, date presets and severity filtering, with CSV, Excel and PDF export |
| 3.3.8 Protect audit information | Append-only tables that reject edits and deletes, secrets redacted, and audit access limited by permission |
| 3.3.9 Limit audit management to a subset of privileged users | Separate permissions to view and to export, and replaying a recording needs the audit permission |
The same evidence serves other frameworks that ask who did what and when, from SOC 2 to ISO 27001 to your cyber insurer's questionnaire. For where the management platform itself sits in your compliance scope, read Is your AVD management platform inside or outside your compliance boundary?
Who can see the audit trail
Access to the audit trail is a permission, not an assumption. Atlas has separate permissions to view and to export audit records, and two built-in roles that grant them without handing out admin rights: Security Officer, and Auditor (read-only + audit export). You can give an outside assessor, or the compliance lead at a client, read access to the evidence without letting them change anything.
Frequently asked questions
Does Atlas record every keystroke in the admin console?
No. In the Atlas console, Atlas records actions (every change, with before and after values), sign-ins and the pages each administrator opens. It doesn't record mouse movements or keystrokes there. In an Atlas Reach remote session, the whole session is recorded, and each action in it is audited.
Can an administrator delete or edit audit entries?
No. The audit tables reject updates and deletes at the database level, whoever is signed in. Only Atlas's own background processes can remove records, under a dedicated database role: the scheduled retention sweep, a data-erasure request, and removing a tenant entirely. A data-erasure request pseudonymises the person rather than removing their actions from the trail.
Which plans include the audit trail?
The Security → Audit page and its exports are included on every Atlas AVD plan. Session Replay is included on Atlas AVD, and Atlas Reach is an add-on. See Atlas AVD pricing explained.
How long are audit records kept?
Infrastructure changes are kept for a year, and Entra ID sign-in logs and directory audits for a year. Atlas Reach recordings follow your Recording Retention setting, which defaults to 30 days.
Are changes made by automation recorded?
Yes. Scaling, scheduled actions and other automatic changes are recorded under a named system actor, so you can always tell a person's change from Atlas's.
Can I give an external auditor access?
Yes. Assign the built-in Auditor (read-only + audit export) role. It can read and export audit records but can't change your environment. Or export the evidence as CSV, Excel or PDF and send the file.
Where is the audit data stored?
In your tenant's own database, inside your own Azure tenant. Atlas AVD runs inside your Azure tenant, so your audit trail stays there too.