Security Activity
Security Activity shows what is happening around security in your environment in a single chronological feed. It is not only about attacks that already happened; it brings configuration changes, deviations, approvals and the monitoring lifecycle together in one place.
There used to be a technical, repetitive "Records" screen for this need. We removed it; everything now lives under Security Activity. Old links redirect here automatically. The underlying audit and record infrastructure was not removed — we only built a single, clear surface on the customer side.
What it shows
The following sources merge into one timeline:
- Verified Conditional Access changes in Microsoft Entra
- TrueState deviations
- VIP Guard identity and mailbox events
- TrueState lock and baseline approvals
- Re-baseline operations
- Exception add and remove
- Project mode and monitoring pause / resume
- CCM activation, deactivation, license and lifecycle events
- Approval and governance operations
- Security-relevant admin changes such as alert recipients and time zone
What it does not treat as an event
Scan counters, schema diffs and purely operational metric changes are not added to the default list as events. For example, the number of open alerts dropping from 17 to 13 is not, on its own, evidence of an investigable event; it does not mean a security setting changed.
If a source only keeps an aggregate count, we do not manufacture a fake individual event from it. Without object-level verified evidence, it does not appear in the list.
Scan observation vs verified event
This distinction matters:
- Scan history shows the configuration difference observed between two snapshots. On its own it does not prove the exact time of the change or who made it.
- A verified event, when it is backed by a source such as the Microsoft Entra audit log, can also show the exact time, who acted, the affected scope and the security impact.
A control result changing is not the same as "these controls read this configuration". Control relationships are not surfaced as primary information, to keep the screen uncluttered.
For complex fields such as Conditional Access policies, raw JSON is not the main view. A change is summarized meaningfully by policy name and id. Raw or technical detail opens only in a technical-evidence layer, and only when it is genuinely needed.
Filters
You can filter by source:
- Microsoft Entra
- TrueState deviations
- VIP Guard
- Approval & governance
Date range and pagination
Default date ranges are 7 days, 30 days, 90 days and 1 year. The maximum history you can query from the interface is 1 year (366 days).
The list shows 20 records per page, with numbered pagination (1, 2, 3, 4…) at the bottom. A year of data is not loaded into the browser at once; records are fetched in batches in the background, and the next batch is pulled only when you move to a page that has not been loaded yet.
When you change the date range, the screen is not torn down and rebuilt. Your workspace stays visible, only the record list updates, and an "Updating the activity list" status is shown while it does.
Roles and masking
Identity data is masked by default. For example, operator@company.com appears as o***@company.com. Immutable user/object identifiers (GUIDs) are not presented as raw technical identity in the customer interface.
Masking is applied on the API that produces the response; it is not merely a visual hide. Including active Global Administrator and Security Administrator roles, everyone sees masked values in the standard Security Activity response.
During a real incident investigation, seeing the full identity may be necessary. The Evidence Access feature designed for this is planned to grant short-lived access for a single selected record only, by an active Global Administrator or Security Administrator, with a justification and re-authentication. This feature is not yet available; no permanent or bulk unmasked view is provided.