Compliance scan permissions¶
Scan Ninja's Compliance Validations scans authenticate to your cloud and read its configuration to produce compliance evidence. This page lists exactly what access to grant for Microsoft Azure / M365, Amazon Web Services, and Google Cloud.
One scan, three frameworks — read-only
A compliance scan reads your cloud's control plane once and records each control's result as CMMC / NIST 800-171 evidence. Scan Ninja then maps every result to FedRAMP and TX-RAMP (NIST 800-53 Rev 5) automatically. You do not grant different access per framework — the permissions are per cloud, and they are always read-only. CMMC, FedRAMP Low/Moderate/High, and TX-RAMP Level 1/2/3 all read the same resources; the framework and level only change which baseline your results are scored against.
HIPAA is a separate scan
HIPAA reads the same Azure surfaces with the same read-only access, but it is its own scan type rather than a mapping of the CMMC results, because it needs two things the others don't: your entity type (covered entity or business associate) and the scope of ePHI. See HIPAA Security Rule scans.
Least privilege, no secrets stored
The scanner never needs write, delete, or administrative permissions on any cloud. No cloud secret is ever written to our database or logs. You either grant a role the scanner assumes (AWS), or you approve a read-only Scan Ninja application whose credential is generated straight into a dedicated Azure Key Vault that Scan Ninja manages for your organization. A scan references that credential only by pointer (the vault URL + secret name) and resolves it at scan time. Nobody, including you, ever sees or sends it.
You choose the cloud in the Create Scan wizard (Compliance Validations → pick a framework → Target Cloud), then fill in the fields below.
Microsoft Azure / M365¶
Azure has two independent surfaces. Azure Resource Manager (ARM) is always read. Microsoft 365 / Graph is read only when you enable the "Also run Microsoft 365 (Graph) checks" toggle (the full Azure + M365 sweep).
How the scanner signs in to your tenant¶
The hosted Scan Ninja scanner runs in Scan Ninja's own Azure tenant, so it reaches yours through an application that you approve. Setup takes about ten minutes and you never handle a secret. It needs two roles, which may belong to different people: an Entra administrator who can grant admin consent (step 2) and a subscription Owner or User Access Administrator (step 3).
- Scan Ninja creates the application. We register a read-only, multi-tenant application named for your organization (Scan Ninja Platform - Compliance Scanner (Your organization)) that requests only the Graph permissions listed below. Its credential is generated straight into a dedicated Azure Key Vault that Scan Ninja manages for your organization. Only the production scanner can read that vault.
- An Entra administrator approves it. A Global Administrator or
Privileged Role Administrator opens the admin consent link Scan Ninja sends,
of the form
https://login.microsoftonline.com/<your-tenant-id>/adminconsent?client_id=<application-id>&redirect_uri=https://scanninja.ai/. Opening it shows the exact read-only permissions requested; clicking Accept adds the application to your directory under Enterprise applications, then lands on scanninja.ai. - A subscription Owner or User Access Administrator assigns
Reader. Assign the built-inReaderrole to the application on each subscription in scope (see ARM below). Scan Ninja provides a short script that does this and prints the consent link for step 2. - Scan Ninja completes the scan configuration. The Tenant ID and Client (App) ID are filled in for you, and the Key Vault pointer refers to the vault from step 1.
To revoke access at any time, delete the application under Entra ID →
Enterprise applications and remove its Reader assignment. Scans stop
immediately.
Federated sign-in: no secret at all¶
Scan Ninja can set the application up so that no credential exists for it
anywhere. Instead of a client secret, the scanner proves who it is with a
short-lived identity token issued by Scan Ninja's own scanning cluster, and the
application accepts only tokens from that cluster's identity issuer that are
bound to your organization's Scan Ninja account. There is no secret to store,
rotate or leak. Your side of the setup is unchanged: admin consent and
Reader.
Ask your Scan Ninja contact to move an existing scan to federated sign-in; the scan then uses the Tenant ID and Client (App) ID only, and the stored secret is deleted.
Prefer to own the application?
If your policy does not allow third-party multi-tenant applications, you can
register a single-tenant application in your own directory, grant it the
read-only permissions below and Reader, and add a federated credential
to it with the issuer, subject and audience values Scan Ninja gives you. No
secret is created on either side, and you can revoke the trust at any time by
deleting that federated credential.
A Key Vault in your own tenant cannot be used with the hosted scanner
Azure Key Vault only accepts sign-ins from identities in the vault's own tenant. The hosted scanner's identity lives in Scan Ninja's tenant, so it can never read a vault in your tenant, whatever role or access policy you grant on it. A scan pointed at such a vault fails with Key Vault pointer unreadable. Put your own vault in the scan only when the scanner itself runs inside your tenant (a self-hosted deployment arranged with Scan Ninja), and then grant that scanner's managed identity the Key Vault Secrets User role on the vault.
Microsoft 365 and Azure in different directories
A scan signs in to one Entra ID tenant. If your Microsoft 365 users and your Azure subscription live in different tenants, approve the application in each one and tell your Scan Ninja contact; each tenant is scanned separately.
Azure Government
An application registered in Azure commercial cannot be approved in an Azure Government tenant. Talk to your Scan Ninja contact before setting up a Government scan.
ARM — subscription resources¶
Assign the built-in Reader role, scoped to the subscription(s) you want
assessed (not the whole tenant unless you intend to scan everything). Reader is
read-only and covers everything the scan inspects:
- Storage accounts, disks, and Key Vaults
- Virtual networks and network security groups
- Virtual machines and compute configuration
- Microsoft Defender for Cloud assessments and secure score
- Azure Policy compliance state
- Recovery Services (backup / disaster recovery)
- Diagnostic settings (the audit-logging pipeline)
Tighter than Reader
If your policy disallows the broad Reader role, use a custom role that
grants only the */read actions on the resource types above. Never assign
Contributor or Owner.
Microsoft 365 / Graph — only with the M365 toggle¶
The Scan Ninja application requests these admin-consented, read-only application Graph permissions and nothing else:
| Permission | Used for |
|---|---|
Directory.Read.All |
users, groups, roles, conditional access |
Policy.Read.All |
authentication / MFA / conditional-access policies |
DeviceManagementConfiguration.Read.All |
Intune compliance policies |
DeviceManagementManagedDevices.Read.All |
device compliance |
AuditLog.Read.All |
sign-in and audit logs |
InformationProtectionPolicy.Read.All |
sensitivity labels / DLP |
SecurityIncident.Read.All |
Defender / Sentinel incidents — HIPAA scans only |
Admin consent requires a Global Administrator or Privileged Role Administrator (step 2 above).
Intune checks need this app, not the Azure CLI
DeviceManagementConfiguration.Read.All and
DeviceManagementManagedDevices.Read.All must be granted on this
application. The Azure CLI's own first-party application does not hold
DeviceManagement scopes, so device and workstation controls cannot be read
through a plain az-based credential. Without this app, those controls report
partial, not fail.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Target Cloud | Microsoft Azure / M365 |
| Azure Subscription ID | the subscription to assess |
| Azure Environment | Commercial, or Government for FedRAMP High / DoD IL4+ (sovereign endpoints) |
| Tenant ID / Client (App) ID | your Entra tenant ID and the Client ID of the Scan Ninja application you approved (Scan Ninja fills these in) |
| Federated sign-in (no secret) | on when Scan Ninja has set up federated sign-in for your application; the Key Vault fields are then not needed |
| Key Vault URI + Secret Name | pointer to the application's credential in the vault Scan Ninja manages for your organization (Scan Ninja fills these in; never paste a secret). A vault in your own tenant works only with a self-hosted scanner, see above |
| Microsoft 365 toggle | on = full Azure + M365 sweep; off = ARM only |
Running with ARM-only credentials is fine — the M365 controls simply report partial instead of failing.
Per-user evidence export¶
By default the M365 checks report tenant-level totals ("42 enabled accounts").
Assessors normally want the underlying list, so the scan can additionally emit
row-level tables: the full user roster with job title, hire date and creation
date, the disabled-account list, the leaver Disable account audit events with
timestamps, the Global Administrator roster, and role and group change history.
Turn it on per scan:
No extra permission is needed. The scopes in the table above already cover it.
Entra retains audit events for a limited window
Directory audit events, including the leaver and role-change events, age out of Entra ID after a retention window that is commonly 30 days. For an audit period longer than that window, run the compliance scan on a schedule through the period so each run captures its own window. A single scan at the end cannot recover events that have already aged out.
HIPAA Security Rule scans¶
HIPAA scans read the same Azure and M365 surfaces as every other framework —
Reader on the subscription plus the Graph app above. Two things differ.
One extra Graph permission. SecurityIncident.Read.All lets the scan read
security incidents when confirming that a breach-response workflow exists
(§ 164.308(a)(6)(ii)). Everything else HIPAA needs, including the
sensitivity-label check for identifying ePHI, is already covered by the
permissions above.
Sentinel analytics and automation rules need no extra permission
The other half of the § 164.308(a)(6)(ii) check — do enabled analytics rules
and an automation rule / playbook actually exist — reads
Microsoft.SecurityInsights resources through Azure Resource Manager,
not Microsoft Graph. Those are already covered by the subscription-scoped
Reader role above. Only the incident read goes through Graph.
You must tell us where ePHI lives. This is the one framework where scoping is not optional:
| Wizard field | What to provide |
|---|---|
| Entity Type | Covered Entity or Business Associate — selects which organizational requirements (§ 164.314) apply |
| ePHI Resource Groups | the resource groups holding electronic protected health information, e.g. rg-ehr-prod |
| ePHI Tag Filter | (alternative) a tag identifying ePHI resources, e.g. dataClassification=ePHI |
An unscoped HIPAA scan is worse than no scan
Without an ePHI scope, every check runs against every resource in the subscription. Marketing websites and build agents get assessed as though they held patient data, and the resulting gap list buries the findings that matter. Scope to the resource groups or tags that actually handle ePHI.
Roughly a third of the Security Rule cannot be scanned by anyone. Of the 51 assessable items in 45 CFR Part 164 Subpart C, 20 are facility, workforce, and policy requirements with no cloud signal — sanction policy, workforce clearance, facility security plan, maintenance records, training delivery. These are flagged needs attestation and you upload the evidence. No credential changes that.
Addressable is not optional
22 of the 51 items are Addressable, which does not mean optional. You must implement the specification, document an equivalent alternative, or document why it is not reasonable and appropriate and accept the residual risk. When an automated check fails on an Addressable item, Scan Ninja records an addressable gap and prompts you to choose — it does not report a violation.
Business Associate Agreements are never auto-verified
Scan Ninja does not assert that your Microsoft BAA is signed. Azure BAA coverage is extended through the Microsoft Product Terms and Data Protection Addendum for eligible agreements, and it is not readable from any API. The scan reports the eligibility signals it can observe and asks you to confirm the agreement — BAA status (§ 164.314(a)(2)(i)) always carries an attestation.
Amazon Web Services¶
Grant a single read-only IAM role and let the scanner assume it. The simplest
option is AWS's managed SecurityAudit policy (read-only across services). If
you prefer a tighter custom policy, grant only these actions:
| Area | Read-only actions |
|---|---|
| S3 (public access, encryption, TLS) | s3:ListAllMyBuckets, s3:GetBucketPublicAccessBlock, s3:GetEncryptionConfiguration, s3:GetBucketPolicy |
| IAM (MFA, password policy, root keys) | iam:GetAccountSummary, iam:GetAccountPasswordPolicy |
| CloudTrail (audit logging) | cloudtrail:DescribeTrails |
| KMS (key management + rotation) | kms:ListKeys, kms:GetKeyRotationStatus |
| EC2 security groups (network boundary) | ec2:DescribeSecurityGroups |
| GuardDuty (threat monitoring) | guardduty:ListDetectors |
| AWS Config (baseline / inventory) | config:DescribeConfigurationRecorders, config:DescribeConfigurationRecorderStatus |
Recommended: cross-account AssumeRole¶
Create a read-only role in the target account that trusts Scan Ninja's scanner, protected by an External ID (this prevents the "confused deputy" problem). No long-lived key ever leaves your account.
Trust policy (attach the SecurityAudit managed policy, or your tighter custom
policy, to this role):
{
"Effect": "Allow",
"Principal": { "AWS": "<scan-ninja-scanner-principal-arn>" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "<your-external-id>" } }
}
Scan Ninja provides the scanner principal ARN to put in
Principal. Choose your own External ID and enter the same value in the wizard.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Target Cloud | Amazon Web Services |
| AWS Account ID | the 12-digit account to assess |
| Region | e.g. us-east-1; use a us-gov-* region for GovCloud (FedRAMP High) |
| AssumeRole ARN | the ARN of the read-only role above (recommended) |
| External ID | your chosen confused-deputy guard value |
| Key Vault URI + Secret Name | (alternative to a role, not recommended) pointer to read-only access keys held in the Key Vault Scan Ninja manages for your organization. Ask your Scan Ninja contact how to hand the keys over; the role above needs no key at all |
Google Cloud¶
Grant read-only IAM on the project you want assessed. One combination covers everything the scan reads:
roles/iam.securityReviewer— read the IAM policy and audit configsroles/viewer— read resource configuration
Prefer granular viewer roles if roles/viewer is broader than your policy allows:
| Area | Granular read-only role |
|---|---|
| Cloud Storage (public access, CMEK, uniform access) | roles/storage.bucketViewer |
| Cloud Logging (sinks / retention) | roles/logging.viewer |
| Cloud KMS (key rings) | roles/cloudkms.viewer |
| VPC firewalls (default-deny, open ports) | roles/compute.viewer |
Never grant editor or owner
roles/iam.securityReviewer + roles/viewer is entirely read-only. Do not
grant roles/editor or roles/owner.
Authenticate with Workload Identity Federation (no key material — preferred) or a service-account JSON held in the Key Vault Scan Ninja manages for your organization and referenced by pointer. Ask your Scan Ninja contact how to hand the JSON over.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Target Cloud | Google Cloud |
| GCP Project ID | the project to assess |
| Key Vault URI + Secret Name | (optional) pointer to the service-account JSON in the Key Vault Scan Ninja manages for your organization; omit when using Workload Identity Federation |
GitHub¶
Change-management evidence (SOC 2 CC8.1, NIST 800-171 3.4.3 and 3.4.4) comes from your GitHub organization: branch-protection settings, the merged pull request approval trail for a date range, and the organization roster with two-factor enforcement state.
Create a fine-grained personal access token scoped to the organization, with read-only access and nothing else:
| Token setting | Value |
|---|---|
| Resource owner | the organization being assessed |
| Repository access | all repositories in scope for the audit |
| Repository permissions | Contents: Read, Metadata: Read, Pull requests: Read, Administration: Read |
| Organization permissions | Members: Read |
Administration: Read is what exposes branch-protection settings; without it
those controls report partial. Scan Ninja stores the token in the Key Vault
it manages for your organization, exactly like the Azure application's
credential, and the scan references it by pointer. Never paste a token into
the wizard; ask your Scan Ninja contact how to hand it over.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Scan type | GitHub compliance (github_compliance) |
| Organization | your GitHub org login |
| Repositories | the repositories in audit scope |
| Key Vault URI + Secret Name | pointer to the token in the Key Vault Scan Ninja manages for your organization (Scan Ninja fills these in) |
| Audit period | period_start and period_end bounding the merged-PR export |
Approvals submitted after a pull request merged are excluded from the export, because a post-merge approval does not evidence pre-merge authorization.
Availability
The GitHub connector is in final review and ships in the next scanner release. Ask your Scan Ninja contact for current status.
What one scan produces¶
- The scan verifies each automatable control and records it as CMMC / NIST
800-171 evidence (e.g. control
3.13.16, "protect CUI at rest"). - Each result is mapped to the equivalent NIST 800-53 Rev 5 controls (e.g.
SC-28) and stored under both FedRAMP and TX-RAMP labels. - Your FedRAMP impact (Low / Moderate / High) or TX-RAMP level (1 / 2 / 3) selects which 800-53 baseline the same results are scored against.
A HIPAA scan instead records each result against the implementation specifications of 45 CFR Part 164 Subpart C, scoped to the ePHI resource groups you nominate, and reports a weighted risk score (0–100%) rather than an SPRS score — the Security Rule has no numeric score to submit anywhere.
Coverage is an honest, automatable subset per cloud — Azure is the deepest, while AWS and GCP cover the controls that map cleanly to their APIs. Controls that can't be verified by API (physical, personnel, and policy controls) are handled as attestations, never marked automatically satisfied.
Evidence, not an attestation
Compliance scans produce evidence to support your assessment — they are not a FedRAMP/TX-RAMP authorization or a substitute for an assessor. See the Compliance overview for how Scan Ninja evidence fits your audit.