StandardOS connects read-only to the systems you already run, reads specific settings on a schedule, and turns each reading into an evidence entry against the Annex A control it supports. A passing check keeps that entry fresh. A failing one lets it expire, so the regression shows up in your notifications rather than in the audit.
systems, all read-only
12
connect in one click
3
of the 93 Annex A controls get evidence
52
Amazon Web ServicesMicrosoft Entra IDGoogle WorkspaceMicrosoft IntuneMicrosoft AzureGoogle CloudJamf ProPersonioGitHubKandjiOktaSnyk
GitHub
Microsoft Entra ID
Okta
Google Workspace
Personio
Amazon Web Services
Microsoft Azure
Google Cloud
Snyk
Kandji
Jamf Pro
Microsoft Intune
Read-only APIs. No agent on anyone's laptop.
Every credential below is granted the permissions listed under it and nothing else, and every one of them is a read permission.
Read more
Nothing StandardOS holds can change a setting, push a command or enrol a device. Device posture is read from the MDM you already run. Software on employees' machines is the loudest complaint about the incumbents and, in a European works council, a conversation about monitoring before it is a control. We do not have that conversation because we do not install anything.
Between them the 12 connections produce evidence for 52 of the 93 Annex A controls. Each control page names the reading behind it, and each card below links to the controls it covers.
3 connect in one click
You sign in with the provider, approve read-only access on its consent screen, and the first checks run before you are back on the page. Nothing to paste, nothing to create in a console.
GitHub
8 checks
Whether two-factor authentication is required, which repositories are public, whether default branches require review, how long Dependabot findings stay open, whether merges require passing status checks, and whether deployments go through a protected environment.
How many people hold Global Administrator, whether guest accounts exist, whether multi-factor authentication is actually required to sign in, and whether Global Administrator is activated through PIM or held permanently.
The other 9 take a read-only credential you paste, with the fields listed on each card.
Every system: what it checks, and what it can see
Identity and directory
One click
Microsoft Entra ID
How many people hold Global Administrator, whether guest accounts exist, whether multi-factor authentication is actually required to sign in, and whether Global Administrator is activated through PIM or held permanently.
What it checks
Global administrators are few and accounted for
External guest accounts are known
Multi-factor authentication is required to sign in, by security defaults or an enabled conditional access policy
Global Administrator is activated just in time, not held permanently
Legacy authentication is blocked
Directory roles are covered by an MFA policy
A policy requires a compliant or joined device
No enabled account has gone 90 days without signing in
Application secrets and certificates live two years at most
Guest invitations are restricted and guests see little
Every administrator has a second factor registered
What the credential can see
Directory.Read.All
Policy.Read.All
RoleManagement.Read.Directory
An administrator approves the read permissions listed on Microsoft's consent screen, once; only your tenant id is kept, and each run signs in with our application's own credentials. Every permission is a read permission, so nothing in the tenant can change.
Your people, to keep the employee register current, the account states that mean somebody was never fully onboarded or never fully offboarded, and who holds Super Administrator.
What it checks
Directory users are synchronized into the employee register, and anyone active here but gone from Okta is named
No accounts are stuck part-way through joining
Suspended accounts are accounted for
Locked-out accounts are visible
Super Administrator is held by few, named people
No active account has gone 90 days without signing in
Every super administrator has an active factor enrolled
Administrator roles are held by few accounts
What the credential can see
okta.users.read
okta.roles.read
A read-only API token. It inherits the permissions of the administrator who creates it, so it is created as a read-only administrator, whose view includes who holds which admin role.
An administrator signs in and approves the single read-only directory scope on Google's consent screen; the checks read the directory as that administrator and can change nothing in it. No service account, no key file.
Your people from the HR system, to keep the employee register current: who is active, on leave or onboarding, and who has left.
What it checks
Directory users are synchronized into the employee register, and any leaver in Personio still active here is named
The HR system is the source of the employee register
Every leaver carries a termination date
No active employment has passed its contract end date
Every active employment names a supervisor
What the credential can see
personio:persons:read
A custom integration under Marketplace, Connected integrations, with the single persons-read scope. Personio's API does not take a subdomain; the credential identifies the company, and nothing here writes to an HR record.
Root account MFA and access keys, console users without MFA, access key age, the account password policy, the account-level S3 public access block, CloudTrail coverage, RDS encryption, backup retention and Multi-AZ, whether an AWS Config recorder is running, whether any EC2 instance runs in the default VPC, whether GuardDuty is enabled, who holds AdministratorAccess as a standing user, and whether each Systems Manager-managed instance carries a time-synchronisation service.
What it checks
The root account has multi-factor authentication
The root account has no access keys
Everyone with console access uses multi-factor authentication
Access keys have been rotated within 90 days
A password policy is set on the account
S3 public access is blocked for the whole account
API activity is logged across every region
Databases are encrypted at rest in the region you name
Databases keep automated backups for at least a week
Databases survive the loss of an availability zone
Resource configuration is recorded continuously
No workload runs in the default VPC
Threat detection is switched on
Full administrative access is held through roles, not standing users
Managed instances run a time-synchronisation service
No console password or access key sits unused for 90 days
The root account is not used for daily work
New EBS volumes are encrypted by default
No security group opens SSH, RDP or a database port to the internet
Every VPC records flow logs
Customer-managed KMS keys rotate automatically
IAM Access Analyzer watches for resources shared outside the account
A backup plan is scheduled
CloudWatch alarms carry an action that reaches someone
Container images are scanned for known vulnerabilities on push
AWS has a security contact to write to
Capacity is watched
A backup plan copies to another region or vault
What the credential can see
arn:aws:iam::aws:policy/SecurityAudit
An IAM user holding one AWS-managed policy, SecurityAudit, which is read-only by construction. Naming the policy rather than listing actions means nobody assembles an over-broad policy by guessing, and you can verify it is the one AWS publishes.
Storage accounts that allow public blob access or plain HTTP, SQL databases without transparent data encryption, their backup retention and zone redundancy, subscriptions whose activity log ships nowhere durable, network security groups that open SSH or RDP to the internet, storage lifecycle policies, and which Defender for Cloud plans are on.
What it checks
Storage accounts do not allow public blob access
Storage accounts require HTTPS and TLS 1.2 or later
SQL databases are encrypted at rest
SQL databases keep point-in-time backups for at least a week
SQL databases survive the loss of an availability zone
Subscription activity is logged somewhere durable
No network security group opens SSH or RDP to the internet
Storage accounts have a lifecycle policy for ageing data
Defender for Cloud watches at least one resource type
Key Vaults have soft delete and purge protection
Storage accounts keep deleted blobs for a while
SQL servers audit access
No SQL server firewall rule admits the whole internet
Network security groups record flow logs
Defender for Cloud has a security contact to notify
Azure Policy is assigned on every subscription
A Recovery Services vault backs something up
What the credential can see
Reader (Azure role, on each subscription in scope)
The Entra ID app registration, given the built-in Reader role on each subscription you want read. Reader is read-only by construction, assigned per subscription, and the same registration already connects Entra ID and Intune.
Buckets readable by the public, Cloud SQL instances without TLS or open to the internet, service account keys past rotation, data-access audit logging per project, and firewall rules that open SSH or RDP to the world, and whether each Cloud SQL instance takes automated backups and runs across zones, and whether each bucket has a lifecycle rule.
What it checks
No Cloud Storage bucket is readable by the public
Cloud SQL instances require TLS and are not open to the internet
Cloud SQL instances take automated backups
Cloud SQL instances survive the loss of a zone
Cloud Storage buckets have a lifecycle rule for ageing data
Service account keys have been rotated within 90 days
Data access audit logs are enabled across all services
No firewall rule opens SSH or RDP to the internet
Cloud Storage buckets keep object versions
Cloud Storage buckets use uniform bucket-level access
Cloud SQL instances are protected from deletion
No person holds the basic Owner or Editor role
No virtual machine has a public address
Subnetworks record flow logs
No project keeps the default auto-mode network
Cloud KMS encryption keys rotate on a schedule
Google has a security contact for every project
What the credential can see
roles/iam.securityReviewer (project role)
A service account key with the built-in Security Reviewer role on each project in scope. The role is read-only by construction, and every active project the account can see is read; nothing here writes.
Whether two-factor authentication is required, which repositories are public, whether default branches require review, how long Dependabot findings stay open, whether merges require passing status checks, and whether deployments go through a protected environment.
What it checks
Two-factor authentication is required across the organization, or enabled on the account
Source code repositories are private
Default branches require review before merging
Dependabot findings are fixed inside the remediation interval: 14 days for critical, 30 for high, 90 for medium, 180 for low
Default branches require tests to pass before merging
Production deployments go through a protected environment
Every repository names its code owners and runs a workflow on change
Nobody outside the organization can push without an agreement
What the credential can see
read:org
repo (read-only)
security_events (read-only)
read:user
A GitHub App you install on your organization from GitHub's own screen, with the read-only permissions listed; nothing is pasted. Each run asks GitHub for a token that lives an hour, so no token of yours is stored.
Open issues measured against your remediation intervals, whether every project is actually being scanned, and whether any project's last test is too old to mean anything.
What it checks
Open findings are fixed inside the remediation interval: 14 days for critical, 30 for high, 90 for medium, 180 for low
Every project has been tested, so a project with no findings is one that was scanned rather than one that was skipped
Every project has been tested in the last 30 days
No secret is committed in a scanned repository
Ignored high and critical issues are decided, not forgotten
Pull requests are tested before they merge
What the credential can see
Viewer (read-only)
An API token from an account holding the Viewer role on the organization. Nothing here writes.
Disk encryption and screen lock across your Apple fleet, and which devices have stopped checking in. Read from the MDM you already run, with no agent of ours anywhere.
What it checks
Managed devices are encrypted at rest
Managed devices lock when unattended
Managed devices have checked in within 30 days
Managed Macs have a recovery lock or firmware password
Managed devices are supervised, so management cannot be removed
Managed Macs carry no more than one local administrator
What the credential can see
Device List (read)
Device Details (read)
An API token scoped in Kandji's own settings to the two device read permissions. Nothing here writes.
FileVault, screen lock and Gatekeeper across your Mac fleet, and which devices have stopped checking in. Read from the MDM you already run, with no agent of ours anywhere.
What it checks
Managed devices are encrypted at rest, counting a Mac as encrypted only when every account on it is
Managed devices lock when unattended
Managed devices run endpoint protection, read from Gatekeeper
Managed devices have checked in within 30 days
Managed Macs run the application firewall
No managed Mac logs in automatically at boot
System Integrity Protection and full secure boot are on
What the credential can see
Read Computers
Read Computer Inventory Collection
An API client with an API role holding exactly two read privileges, exchanged for a short-lived token. Not the Classic API's username and password, which would be a credential that can also wipe a laptop.
Disk encryption across your managed devices and which have stopped syncing. The same app registration as Entra ID, with one more read permission.
What it checks
Managed devices are encrypted at rest
Managed devices have checked in within 30 days
Managed devices meet their compliance policies
No managed device is jailbroken or rooted
A threat defense partner reports every managed device as secure
What the credential can see
DeviceManagementManagedDevices.Read.All
The Entra ID app registration with one further application permission, consented once. A customer who has connected Entra adds the permission and connects this with the same client ID and secret.
1. You connect, and the credential is checked before it is kept
The credential is tried against the vendor first. If it works, it is stored where no browser session can read it, and the first run happens immediately so you see results before you leave the page.
2. Every check runs daily and keeps one evidence entry
A passing check extends the entry's validity. A failing check pulls it back to today, so it expires the way a lapsed certificate does and appears in the same place. A check that could not read what it needed says so, and says which permission to grant, rather than reporting a failure it did not observe.
3. A pass that turns into a fail emails your administrators
Once, when it flips. A setting that was right last night and is wrong this morning is the one event worth an email; a setting that has been wrong for a month is already in your notifications.
What is not integrated
The question a feature-count comparison is really asking. Here is the answer, so you do not have to find it out after signing up.
An agent on anyone's laptop
Deliberately, and permanently. Everything about a device is read from the MDM you already run. Endpoint agents are the loudest complaint about the incumbents, and in a European works council they are a conversation about monitoring software before they are a control.
Other HR systems
Personio is read; BambooHR, HiBob, Workday and the rest are not. For a company whose people live in Okta or Google Workspace first, those keep the register current instead.
Ticketing, chat and logging platforms
Incident and change records are kept in StandardOS itself, on its own hash chain. Nothing is read from Jira, Slack or a SIEM.
Connected in minutes, read every night
Each connection is a form with the fields above and nothing else. The export your auditor receives is organised by Annex A reference, and every automated entry in it names the system it was read from and the day it was read.