What Attestry reads, where it goes, and what it never does.

Where it runs

Attestry's checks are PowerShell modules that run on a computer in your network, under an account you choose. They write files to a folder you choose. There is no Attestry cloud service involved in running a check.

What it reads

• Active Directory: user, computer and group attributes needed for the checks (for example sign-in names, email addresses, last sign-in date, operating system), and optionally domain controller security event logs.
• Microsoft 365: users, MFA methods, admin roles, app permissions, mailbox settings and sync status, through Microsoft Graph and Exchange Online with read-only permissions you approve when you sign in.
• A staff list, only if you supply one.

What it never does

• It never changes Active Directory or Microsoft 365. Fixes are shown as commands for your staff to review and run.
• It never sends data to Attestry or anyone else. No telemetry, no licence call-home.
• It never writes names or addresses to its run logs. Logs hold counts, steps and settings, so they can be shared for support.

Files it writes

A report (HTML), the data it read (JSON) so the report can be rebuilt offline, a CSV when you match a staff list, and a run log with a run summary. Treat the report and data files as confidential: they describe security weaknesses and contain directory data.

Permissions

Active Directory checks need a domain account that can read the directory; reading event logs needs Event Log Readers or Domain Admins. The Microsoft 365 check needs an account with Global Reader or Global Administrator to approve read-only Graph permissions.

This website

This site sets no cookies and loads no trackers, fonts or scripts from other companies. Forms are delivered to our inbox by Web3Forms. See the privacy notice.

Reporting a vulnerability

Email security@attestryhq.com. We acknowledge reports within two business days. See security.txt.