How we keep your tenant safe
Tenant Strike can see your Microsoft 365 and Azure settings. It cannot change them. And you don’t have to take our word for it — the proof, down to every single API call we make, is published on this page.
01
When your admin grants access, the 19 Microsoft permissions we request are all read-only — they let us see configuration, not change it. We don't request any "write" permission, because we don't have any code that could use one.
02
Our scanner lists users, reads policies, and checks settings. It cannot create, modify, or delete anything in your Microsoft 365. The endpoint manifests below show the reads in our code and let you review their permissions. A manifest describes the code; it is not a complete log of requests from an individual scan.
03
Our build process automatically lists every API call in our code and fails the build if any "write" call sneaks in. Your security team can verify it themselves in five minutes — evidence below.
What we look at
Tenant Strike checks the parts of your Microsoft 365 tenant and Azure subscriptions that attackers target. Here's what each surface covers; the full check-by-check list is below.
Sign-in policies, MFA enforcement, admin accounts, guest access, device registration settings, and unresolved user risk reported by Entra ID Protection. We read security configuration and risk state, never passwords.
DMARC, SPF, DKIM, Defender for Office policies, forwarding rules. We never read message content.
SharePoint, OneDrive, and Teams external-sharing settings. We see the settings, not the documents being shared.
Enterprise apps and the permissions they were granted. Useful for spotting OAuth phishing and over-privileged add-ins.
Intune compliance, BitLocker, Defender for Endpoint coverage. We see device status, not what's on the device.
Servers, storage, databases, networking, access and backup across every subscription you connect. Read-only via the Azure Reader role — never Contributor, never Owner.
Whether your audit log is on, where security alerts go, and what gets recorded. The forensics-readiness surface.
What your tenant looks like from the public internet — exposed ports, expired TLS, DNS health. Outside-in, not inside your tenant. We also make read-only HTTPS requests to the portals and domains you list, to read their product/version banners — only to hosts under a domain Microsoft has verified you own, and only when you opt in.
Configuration metadata only.
Never file, mailbox, or chat content.
Latest coverage · September 2026
Checks registration MFA, local administrator defaults for joined devices, and the tenant’s Windows LAPS backup switch. It reads policy configuration, not device passwords or proof that every device backs up its password.
Uses Policy.Read.DeviceConfiguration.
Reports unresolved risk and confirmed compromise identified by Entra ID Protection. Requires Microsoft Entra ID P2 and the corresponding read permission. A missing license or unreadable response is shown as a coverage limitation.
Uses IdentityRiskyUser.Read.All.
Already connected? An administrator may need to refresh scanner consent to grant these two read permissions. Existing grants do not expand automatically. Your scan shows checks it could not verify; missing access is never treated as a pass. The AI assistant’s separate permission list is unchanged.
External scans also distinguish known Cloudflare shared proxy IPs from your origin servers. Shared proxy observations do not become findings about ports or vulnerabilities on your server. An unobserved origin is a coverage limitation, not evidence that the origin is secure.
Permissions we request
These are the 19 Microsoft Graph permissions your admin grants at consent time. They allow reading security configuration and assessment data. No permission in this list grants write access; Tenant Strike cannot change your Microsoft settings.
Directory.Read.AllreadRead users, groups, and role assignments to evaluate admin sprawl, group membership, and guest access. MFA registration and policy enforcement use their respective sources.
Policy.Read.AllreadRead Conditional Access policies, authorization policies, and Security Defaults state.
Reports.Read.AllreadRead sign-in reports and inactive-account reports for stale admin / guest detection.
AuditLog.Read.AllreadVerify that the Unified Audit Log is enabled and check audit ingestion health.
Application.Read.AllreadInspect enterprise apps for risky Graph permissions, expiring secrets, and consent posture.
SecurityAlert.Read.AllreadRead the Defender XDR alerts queue (/security/alerts_v2) so unresolved high-severity alerts are reported. Separate from SecurityEvents.Read.All, which only covers the legacy alerts endpoint.
RoleManagement.Read.DirectoryreadRead PIM eligible role assignments. Without it, admin counts include only standing assignments and undercount tenants that use Privileged Identity Management properly.
ServiceHealth.Read.AllreadRead Microsoft's service-health incidents so the executive brief can answer 'is it Microsoft or is it us' during an outage.
ServiceMessage.Read.AllreadRead message-center posts so Microsoft-imposed deadlines (retirements, forced changes) appear before they bite.
IdentityRiskEvent.Read.AllreadRead Microsoft's own leaked-credential detections, so accounts whose passwords appear in breach dumps are reported. We never see or handle a password — Entra ID Protection does the matching and we read the result.
Policy.Read.DeviceConfigurationreadRead device registration and join policy, including registration MFA, local administrator defaults and the tenant LAPS backup switch. This does not read device passwords or change settings.
IdentityRiskyUser.Read.AllreadRead which users Entra ID Protection currently rates as at risk or confirmed compromised, and whether that risk has been remediated — so an open risk is reported until someone acts on it. Read-only; no password, session or mailbox content is involved.
SecurityEvents.Read.AllreadRead Defender for Endpoint alerts and Microsoft Secure Score data.
SharePointTenantSettings.Read.AllreadRead SharePoint tenant-wide settings — sharing scope, link expiration, sync restrictions, legacy auth.
MailboxSettings.ReadreadDetect inbox-rule forwarding abuse and auto-forwarding misconfigurations — a top BEC indicator.
DeviceManagementManagedDevices.Read.AllreadRead Intune-enrolled devices and their detected-app inventory for compliance posture, BitLocker coverage, and vulnerability matching.
DeviceManagementConfiguration.Read.AllreadRead Intune compliance and configuration policies to confirm enforcement.
DeviceManagementApps.Read.AllreadRead Intune app-protection and app-configuration policies for mobile device coverage.
OrganizationalBranding.Read.AllreadRead your organization's sign-in branding so the dashboard can show your logo. Branding only — nothing else.
AI Assistant · Beta
The AI assistant does not borrow the scanner’s access. It is a separate Microsoft app registration with its own, narrower set of 11 permissions, which your admin consents to separately and can revoke on its own. Three consequences worth being concrete about: authentication appears in your Entra sign-in logs under their own name, “Tenant Strike AI Assistant”, identifying app access rather than every API request; revoking it does not stop your scans; and it is limited to its own consented permissions.
User.Read.AllreadWho your users are — names, addresses, whether the account is active.
Group.Read.AllreadYour groups and who is in them.
Reports.Read.AllreadWhich users have actually registered for multi-factor sign-in.
AuditLog.Read.AllreadSign-in history and recent admin changes.
Policy.Read.AllreadYour Conditional Access rules.
Application.Read.AllreadApps connected to your tenant and what they were granted.
RoleManagement.Read.DirectoryreadWho holds admin roles, including standby (PIM) assignments.
SharePointTenantSettings.Read.AllreadYour SharePoint and OneDrive sharing settings.
DeviceManagementManagedDevices.Read.AllreadWhether your enrolled devices are compliant.
SecurityEvents.Read.AllreadYour Microsoft Secure Score.
ServiceHealth.Read.AllreadMicrosoft outages affecting your tenant.
What it does not ask for
What leaves our servers is a separate question from what we can read, and it deserves a straight answer: your findings go to the AI provider you chose, under your own account and key, and email addresses, IP addresses and display names are replaced with placeholders before they are sent. The full data-handling detail is on the assistant’s page.
Optional external AI connections
Workspaces on either paid plan, on a trial, or managed by an MSP can use the read-only Tenant Strike connector. Sharing starts off. The customer’s administrator must enable it, and each administrator or authorized MSP team member separately approves one tenant for their connection. No AI API key is required.
The connector shares sanitized security facts, scores, findings and conditional attack paths from saved assessments. Names, email addresses, organization and resource identifiers, and customer-written text are withheld. Reference labels can correlate observations; the security information remains confidential, not anonymous. Identifying evidence opens separately after Tenant Strike sign-in.
Its separate Microsoft sign-in app requests only openid, profile and email. It cannot run scans, query Microsoft live, change tenant settings or reuse the scanner’s permissions. You choose a connection duration from 24 hours to six months; 30 days is the default. Access remains subject to current tenant permissions and can be revoked sooner. Revocation stops future reads; it does not remove information already in an AI provider’s chat history, which follows your agreement with that provider.
Continuous monitoring
On Pro, we watch your internet-facing addresses between scans by registering them with Shodan Monitor, which notifies us when one of them changes. This is the one place we routinely hand anything derived from your account to a third party, so here is the whole of it: we send IP addresses and nothing else. No names, no user accounts, no findings, no configuration. Nothing from inside your tenant is involved at any point — this operates entirely on what is already publicly visible from the internet.
Only addresses you provably control: resources read from your own Azure subscription, the A record for your primary domain and its www, and hostnames under a domain Microsoft has verified you own.
Addresses behind a CDN, and shared Azure platform infrastructure. Those are shared with thousands of unrelated sites, so watching one would mean emailing you about a stranger’s server. We record the exclusion and its reason rather than dropping the asset silently.
An email when a watched address changes — a new service or port, a database open to the internet, an expired TLS certificate, or software showing as known-vulnerable or end-of-life.
Storage and encryption
Your scan results live in Microsoft Azure, encrypted the whole way. “Encrypted” is a word that hides a lot, though — it rarely says who can decrypt, or who audited the claim. So here is the whole of it, including the parts we have not done yet.
The dashboard is served over HTTPS (TLS 1.2 or higher). Our application’s own connection to its database enforces TLS with full certificate verification — that link carries every tenant’s data, so an unverified handshake is not an option. Everything we read from your tenant comes over Microsoft Graph on HTTPS.
Scan results, tenant records and backups sit in Azure Database for PostgreSQL, Azure managed disks and Azure Blob Storage, each encrypted with AES-256 using Microsoft-managed keys. Application secrets live in Azure Key Vault and are fetched at deploy time through a managed identity — never committed to the codebase. We hold read-only permissions in your tenant and never receive your users’ passwords.
The keys are Microsoft’s, not ours and not yours — customer-managed keys are not offered today. Data is protected by platform encryption and access control, not encrypted field by field inside the application. And no third party has audited any of this: our encryption meets what SOC 2 (CC6.7), ISO 27001 (A.8.24) and NIST 800-53 (SC-8, SC-28) ask for, but we are aligned with those standards, not certified against them. We would rather you hear that from us than discover it in a questionnaire.
Everything we check
Not a category summary — the actual list, generated from the scanner's own registry when this page was built. Some checks need a specific Microsoft licence to return anything; those say so, and report honestly that they could not run rather than passing you by default.
identity.admin-account-hygieneAdmin work should happen on dedicated cloud-only accounts — no mailbox attached (no inbox to phish), no on-prem sync (no AD compromise = no tenant compromise). This is CIS M365 control 1.1.1.
identity.authentication-methods-policyA code sent by text message or voice call can be stolen with a SIM swap or relayed through a phishing proxy (Evilginx, EvilProxy). Microsoft Authenticator is stronger, and passkeys (FIDO2) are the methods Microsoft counts as phishing-resistant.
identity.break-glass-accountsMicrosoft recommends two cloud-only Global Administrator accounts excluded from Conditional Access, so a bad policy, an expired federation certificate or an MFA outage cannot lock every administrator out of the tenant at once. This is a resilience control: without it, recovery from a lockout runs through Microsoft support and takes days.
identity.ca.admin-mfaChecks a universal MFA baseline or an enforcing policy covering the 14 documented reference admin roles. Exclusions, custom roles and effective sign-ins need separate review.
identity.ca.admin-phishing-resistantA code by text or an app approval can be relayed by a fake sign-in page. Passkeys, Windows Hello for Business and certificate-based MFA cannot. This checks that a Conditional Access policy makes admins use one of those for the same admin roles the admin MFA check covers.
identity.ca.device-code-flow-blockedDevice code flow lets an attacker phish a working access token without a fake login page: the victim types a real code into a real Microsoft sign-in page, completes MFA themselves, and the resulting token goes to the attacker. Almost no organisation needs the flow, and Conditional Access can switch it off.
identity.ca.exclusion-sprawlA Conditional Access policy only protects the people it applies to. Exclusion lists start as two break-glass accounts and grow — an exempt group here, a service account there — until the MFA policy the tenant believes is universal quietly isn't. This check reports who is exempt from the policies that enforce MFA and block legacy authentication.
identity.ca.legacy-auth-blockedChecks for a policy blocking both legacy client types across all users and applications. A restricted or excluded policy cannot establish tenant-wide blocking.
identity.ca.mfa-coverageChecks for a mandatory MFA policy covering modern sign-ins for all users and applications, with policy exceptions and unsupported scopes left for review.
identity.ca.report-only-stalledA Report-only Conditional Access policy is evaluated on every sign-in and then ignored — it writes a verdict to the log and lets the sign-in through regardless. Report-only is the correct place to START a policy, but a policy left there for months is protection the tenant believes it has and does not.
identity.ca.risky-signin-policyWith Entra ID P2 you get Identity Protection — Microsoft scores every sign-in for risk (impossible travel, anonymous IP, leaked credentials, etc.). A CA policy that requires MFA or blocks high-risk sign-ins turns those signals into active defenses.
identity.ca.trusted-locations-broadA location marked trusted is often allowed to skip MFA and counts as lower risk. This flags trusted address ranges of 65,536 addresses or more, which cover far more than one organisation's offices.
identity.default-user-permissionsBy default every user in a Microsoft 365 tenant can register applications, create new tenants and security groups, and read the BitLocker recovery key of their own devices. An attacker who gets into one ordinary account inherits all of that.
identity.device-registration-policyWhether joining or registering a device needs MFA, who may do it, who becomes local administrator during device join, and whether Microsoft Entra allows Windows LAPS backups. These tenant settings do not prove endpoint deployment or compliance.
identity.global-admin-countMicrosoft recommends 2-4 Global Administrators per tenant. Too few = no recovery if one is locked out; too many = oversized blast radius from a single compromised credential.
identity.guest-invite-policyIf 'everyone' or 'all members' can invite guests, any compromised user can create an attacker-controlled guest account, then use it as a persistence mechanism even after the original account's password is reset.
identity.leaked-credentialsMicrosoft Entra ID Protection matches your users against credential dumps found on the dark web and in law-enforcement seizures. An account flagged here has a password an attacker can already look up — the most direct route into a tenant there is, and one that no amount of perimeter hardening closes.
identity.legacy-auth-signinsOld mail protocols such as IMAP, POP and SMTP AUTH sign in with a password alone and cannot ask for MFA. This reads the last 30 days of interactive sign-ins for them: a successful one is access no MFA policy covered, and failed ones are usually someone guessing passwords.
identity.password-expiry-policyForcing people to change their password on a schedule makes passwords weaker: they pick something predictable and change one character each time. Microsoft, CISA and CIS recommend passwords that do not expire, backed by MFA.
identity.recent-privileged-changesLists the privileged changes made in your tenant recently — apps granted access, new app secrets, and accounts given admin roles. These are the first things an attacker does after getting in, because each one survives a password reset. They are also normal administration, so the point is to confirm each one was you.
identity.risky-usersEntra ID Protection rates every user's risk from Microsoft's signals — leaked passwords, anonymous or malicious IPs, impossible travel, token anomalies. A user left at risk is an signal that needs investigation. Open risk or an enabled account does not prove an active attacker or a successful sign-in.
identity.security-defaults-statusChecks Security Defaults configuration or a supported Conditional Access MFA and legacy-auth baseline. Configuration does not establish an MFA challenge at every sign-in.
identity.stale-admin-accountsAdmin accounts that haven't been used in 90+ days are likely former employees or unused service accounts. They hold privilege but receive no ongoing scrutiny — a near-perfect target for a patient attacker.
identity.stale-guest-usersGuest accounts that haven't signed in for 90+ days are likely abandoned but still have access to whatever they were invited to. They're a common lateral-movement vector after a third-party breach.
identity.users-without-mfaReports MFA registration gaps among the member accounts returned by Microsoft's registration report. Registration does not establish policy enforcement or observed authentication.
email.anti-phishing-policyDefender for Office's anti-phishing policy uses ML to detect spoofed and impersonating senders. By default impersonation protection of executives is OFF — every tenant should add their executives explicitly.
email.connection-filter-permissiveIPs in the connection filter allow list bypass Defender for Office's spam/phish/malware scanning entirely. Large ranges, stale entries, or Microsoft's bulk-sender 'SafeList' create permanent backdoors past your email security.
email.defender.antimalware-zapAnti-malware policy blocks common malicious file types regardless of content (executables, scripts). Zero-hour Auto Purge (ZAP) retroactively removes mail from inboxes when Defender later identifies it as malware or phish — critical when threat signatures arrive minutes after delivery.
email.defender.safe-attachmentsSafe Attachments detonates inbound attachments in a sandbox before delivery. Without it, malicious documents reach users immediately, relying on the recipient's endpoint AV — which often runs minutes after the user has already opened the file.
email.defender.safe-linksSafe Links rewrites URLs in email, Teams chats, and Office apps so Microsoft can check them at click time (after attackers' detonation evasion has fired). Microsoft's built-in protection applies a basic Safe Links policy to every licensed mailbox by default. Exceptions to it, the stricter Standard and Strict presets, and Safe Links for Office apps are what an admin controls.
email.defender.tabl-hygieneEach allow entry in the Tenant Allow/Block List bypasses Defender's spam, phish, and malware verdicts for the matching sender/URL/file. Permanent (no-expiration) and forgotten old entries become backdoors past your phishing protection.
email.dkim-recordsDKIM cryptographically signs outbound mail so receivers can verify it wasn't altered or spoofed. Without DKIM, DMARC enforcement is effectively weaker since SPF alone is fragile under forwarding.
email.dmarc-policyDMARC tells receiving mail servers what to do with email that fails SPF and DKIM. Without it (or with p=none), attackers can spoof your domain with impunity — a primary BEC technique.
email.external-sender-tagOutlook's 'External' tag marks every inbound message from outside the tenant. It's a simple but highly effective UX defense against CEO impersonation and fake-IT phishing — users learn to scrutinize external messages that claim to be internal.
email.inbound-mail-tlsMTA-STS tells sending servers to require TLS when delivering mail to your domain, preventing on-path attackers from stripping encryption. TLS-RPT surfaces when delivery TLS is failing or being downgraded.
email.inbox-forwarding-rulesInbox rules are the most common BEC persistence mechanism. Attackers create forwarding rules to exfiltrate mail in real time, or delete/move rules keyed on words like 'phish' or 'security' to hide their tracks. Microsoft's own incident reports consistently rank this as the #1 post-compromise action.
email.mta-sts-policyPublishing the MTA-STS DNS record is only half of it — sending servers also fetch a policy file over HTTPS. If that file is missing or malformed, they ignore your policy entirely and mail can still be downgraded to an unencrypted connection.
email.mx-recordsIf the domain's MX record points somewhere other than M365, mail isn't flowing through Exchange Online Protection — meaning Defender for Office, anti-phish, Safe Links, and the rest of M365's mail filtering aren't actually inspecting inbound mail. Often unintentional after a migration.
email.outbound-forwarding-policyIf users can auto-forward email externally via inbox rules, an attacker who phishes one account silently exfiltrates ALL inbound mail to their own address — surviving password resets and session terminations.
email.outbound-spam-limitsWithout sensible outbound rate limits, a compromised account can send tens of thousands of phishing emails (to internal users, to your customers) before Microsoft's tenant-level limits kick in. Tight per-user limits AND BlockUser action when the limit is hit contain the blast radius of any single account compromise.
email.spf-recordSPF authorizes which mail servers may send for your domain. Missing, soft-fail (~all), or too-many-lookups SPF records let spoofed mail through.
email.transport-rules-riskyA single transport rule can bypass spam filtering tenant-wide, redirect mail to attacker addresses, or strip Microsoft-added authentication headers. Far higher leverage than per-mailbox rules, and far less commonly reviewed.
sharing.cross-tenant.b2b-collaborationBy default, ANY user from ANY external Microsoft Entra tenant can be added as a guest in your tenant. Combined with permissive Teams settings, this lets attackers in any tenant DM and share files with your users — bypassing email security entirely.
sharing.cross-tenant.b2b-direct-connectB2B Direct Connect lets users from other tenants access your data without becoming guests in your directory. This bypasses guest-account lifecycle controls, access reviews, and many CA policies that target guests specifically. Should be enabled only with vetted partner tenants.
sharing.onedrive.sharing-capabilityOneDrive external sharing is controlled by the tenant-wide external sharing setting and, per Microsoft, can only be equal to or more restrictive than SharePoint — never more permissive. This informational check surfaces OneDrive's effective ceiling; the tenant-wide level itself is graded by the SharePoint external sharing check. (The OneDrive-specific override is not exposed by the read-only Graph API.)
sharing.sharepoint-external-sharingWhen SharePoint allows 'Anyone' links, any user can generate an unauthenticated URL that grants access to a file or folder — no sign-in required. These links leak via screenshots, forwarded emails, and search engines.
sharing.sharepoint.anonymous-link-expirationIf Anyone links don't expire, a single leaked URL remains exploitable indefinitely. Forcing a max lifetime (≤30 days is industry standard) limits the damage window when a link inevitably ends up somewhere unintended.
sharing.sharepoint.default-link-permissionWhen users click Share without changing options, the link defaults to this permission level. Edit-by-default means recipients can modify or delete content — including invoices, contracts, customer lists.
sharing.sharepoint.guest-resharingIf guests can re-share, content fans out to people you never invited or audited. Each re-share is invisible to you and survives even if the original guest's access is revoked.
sharing.sharepoint.legacy-authSharePoint has its own legacy-auth toggle separate from the tenant-wide Conditional Access block. When enabled, certain SharePoint-specific basic-auth and ACS-based flows bypass modern identity controls.
sharing.sharepoint.unmanaged-sync-restrictionWithout this restriction, users can sync OneDrive (and SharePoint libraries) to ANY device including personal laptops. A user keeping a synced copy on a personal device circumvents BitLocker, MDM remote wipe, and conditional access — all your tenant controls only apply while the data is in M365.
sharing.teams.anonymous-meeting-joinIf anonymous users can join Teams meetings AND auto-bypass the lobby, attackers can silently join scheduled meetings using only the meeting link — which routinely leaks via calendar invites, support tickets, and screenshots. They can then record audio/video and read chat.
sharing.teams.app-installationIf users can install custom (sideloaded) Teams apps, an attacker who phishes a user can deliver an OAuth-grant attack via Teams — bypassing email security and the typical consent-attack UX users are trained on.
sharing.teams.consumer-federationIf enabled, any person with a free Microsoft account (Teams Personal) can DM and call your users. This is a primary Teams phishing vector — attackers spoof internal user display names and message employees with credential-harvesting links.
sharing.teams.external-domains-restrictedWithout a domain allowlist, your users can be DM'd by users from any external Entra tenant. While the Cross-tenant Access policy controls guest invites, this is the separate control governing who can initiate Teams chats and calls from outside your tenant.
apps.admin-consent-workflowIf you've restricted user consent (recommended), users need a way to request admin approval for legitimate apps. Without an admin consent workflow, users either go without the app or find workarounds.
apps.app-secretsApp registration secrets that expire silently cause outages; secrets with multi-year validity are credential-stuffing magnets if leaked. Both worth knowing about.
apps.delegated-grantsReviews delegated grants against the target API. User-specific consent does not identify who granted consent, and granted scopes do not prove active access or bypass of authentication controls.
apps.privileged-app-ownersWhoever owns an app can add a secret to it and sign in as the app, with all of its permissions and no MFA. This lists apps registered here that hold high-risk Microsoft Graph permissions and are owned by someone who is not an app administrator.
apps.redirect-uri-hygieneA redirect URI is the address Entra delivers sign-in tokens to. Wildcards, plain http, and leftover localhost entries widen that address from one host you control to a range someone else might occupy — turning your own app registration into a token delivery service for an attacker.
apps.risky-permissionsReviews granted application permissions against their target API. Known broad Microsoft Graph grants are flagged; other APIs and unresolved permissions require review. Grants do not prove effective access or exploitation.
apps.sp-credentialsPasswords or certificates added to a service principal (not its app registration) let anyone holding them authenticate as the app. On a third-party app this is the classic persistent backdoor.
apps.unused-app-registrationsAn app registration nobody has used in months, that still holds application permissions or a live secret, is a standing credential with no owner watching it. Nobody notices when it starts being used, and nobody would miss it if it were deleted — which is exactly what makes it attractive to an attacker.
apps.user-consent-policyIf end users can consent to OAuth apps without admin approval, illicit consent attacks succeed: a phishing-like link grants an attacker-controlled app permission to read mail and files, bypassing MFA entirely.
devices.defender.known-vulnerabilitiesReview known vulnerabilities reported by Defender, grouped by affected software with distinct CVE and device counts. A CVE observation is not proof of exploitation.
devices.defender.onboarding-coverageCorporate Windows devices should be covered by Defender for Endpoint/Business (EDR, not just signature AV) with tamper protection enabled so malware can't switch Defender off. This reports the tenant's Defender licensing capability and per-device tamper-protection state — the signals readable via Microsoft Graph. (Per-device MDE onboarding status isn't exposed by Graph; it lives in the Defender portal's machines API.)
devices.defender.security-recommendationsReview active Defender recommendations and documented exceptions for the visible device inventory. Recommendations are grouped into one control rather than counted as individual security checks.
devices.defender.sensor-healthReview sensor health, onboarding state and seven-day reporting freshness for devices returned by the optional Defender connection. This does not establish coverage of every device in the organization.
devices.defender.unresolved-alertsDefender XDR surfaces alerts from MDE, MDO, MDI, and MDA in a unified queue. High-severity alerts in 'New' or 'InProgress' status for >7 days are a strong indicator of either an unstaffed security function or an in-progress incident that's stalled.
devices.intune.app-protection-policiesReviews iOS and Android app-protection assignments. Policy configuration does not establish protection for every app or device; other Intune workloads are outside this check.
devices.intune.bitlocker-complianceWithout BitLocker, a stolen or lost Windows device exposes all cached data — OneDrive sync content, cached Outlook PSTs, saved attachments, Teams cache — to anyone who removes the disk and reads it. Encryption is the foundational endpoint control.
devices.intune.ca-requires-compliant-deviceCompliance policies + enrolled devices only matter if a CA policy actually requires compliance before granting access. Without this grant, an attacker on a non-Intune device can sign in with valid credentials and access corp resources just as easily as a compliant managed device.
devices.intune.compliance-policies-existWithout a compliance policy for a given OS, every device on that OS is in 'unknown' compliance state. CA policies that 'require compliant device' silently let those devices through (or block them all, depending on the rule design) because there's no compliance evaluation.
devices.intune.noncompliant-devicesDevices in 'noncompliant', 'conflict', or 'error' state have failed their compliance policy. With a CA policy requiring compliant devices, they're blocked from corp resources. Without one, they're still accessing data despite failing the controls you've defined.
devices.intune.stale-devicesDevices that haven't synced for 30+ days are likely lost, decommissioned, or belong to former employees. They distort your compliance metrics, occupy licenses, and represent potential offline-data exposure if lost or stolen.
azure-activity-log-alertsActivity Log alerts notify on high-risk operations (role assignment changes, NSG edits, security-solution deletions) in near-realtime. Catching these as they happen beats finding them in a quarterly review.
azure-activity-log-to-laWithout an Activity Log → Log Analytics diagnostic setting, control-plane events (role changes, NSG edits, resource deletes) only retain 90 days natively. Most security investigations need year-plus retention.
azure-app-gateway-wafWAF disabled, or in Detection mode, doesn't block attacks. Production App Gateways should run WAF in Prevention mode (blocks + logs).
azure-app-service-auth-disabledReads App Service platform authentication settings. Apps may intentionally use their own authentication or serve public content; this check does not prove anonymous access or internet reachability.
azure-app-service-https-onlyApp Services should have httpsOnly=true so HTTP traffic is auto-redirected. Avoids credentials and cookies traveling in cleartext during the initial request.
azure-app-service-tls-minReads the App Service web configuration and checks that the application endpoint requires TLS 1.2 or later. Deployment slots and the separate SCM endpoint are outside this check's scope.
azure-backup-coverageEvery virtual machine should be protected by Azure Backup with a healthy, recent recovery point. Unbacked-up VMs are unrecoverable after ransomware, accidental deletion, or a failed change — the restore simply does not exist.
azure-backup-vault-hardeningRecovery Services and Backup vaults should have soft delete enabled so that backup data deleted by a compromised or mistaken administrator is retained and recoverable rather than destroyed immediately.
azure-ddos-protection-standardDDoS Protection Standard mitigates volumetric attacks against public IPs. Only VNets containing public-IP attached workloads are evaluated — pure internal VNets don't need it.
azure-defender-plan-enablementDefender for Cloud's per-workload plans (Servers, Storage, SQL, etc.) provide threat-detection signal on each workload type. Subscriptions on the Free tier only get configuration recommendations — no runtime threat protection.
azure-defender-recommendations-summaryPer-subscription roll-up of the top 5 unhealthy high-severity Defender for Cloud recommendations. Informational — drives the 'what Defender thinks' dashboard panel. Never fails on its own.
azure-diagnostic-settings-coveragePer-resource diagnostic settings forward data-plane logs (storage requests, KV accesses, SQL audits, NSG flow logs) to Log Analytics. Coverage <80% across critical resource types indicates substantial blind spots for forensic investigation.
azure-front-door-wafFront Door WAF is opt-in per frontend. Frontends without an attached WAF policy are unprotected against OWASP attacks and bot traffic.
azure-iam-custom-roles-overbroadCustom roles whose actions include `*`, `*/*`, or `Microsoft.Authorization/*` grant near-Owner privileges and bypass least-privilege. Microsoft.Authorization/* in particular is a privilege-escalation primitive (holder can grant themselves Owner).
azure-iam-guest-rbac-assignmentsReviews direct role assignments using explicit directory evidence. Unknown identities remain unverified; effective access and group membership require separate review.
azure-iam-managed-identity-coverageManaged identities eliminate stored credentials for service-to-service auth. Coverage <50% suggests significant credential-rotation debt; <80% is a hygiene target worth working toward.
azure-iam-orphaned-role-assignmentsReviews direct role assignments using explicit directory evidence. Unknown identities remain unverified; effective access and group membership require separate review.
azure-iam-pim-enabledPIM lets users hold privileged Azure roles as eligible rather than active, requesting just-in-time activation. Substantially reduces standing-access blast radius. Requires Entra ID P2.
azure-iam-sp-broad-scopeService principals holding Owner or Contributor at subscription level have authority across every resource in the subscription. Scope them down to the specific resource groups they need.
azure-iam-sp-stale-credentialsReviews credential dates for directly assigned Azure service principals and their locally owned app registrations. Flags active credentials older than 365 days or configured for more than 365 days. Group-derived access and publisher-owned registrations are not fully assessed.
azure-iam-subscription-ownersMicrosoft recommends ≤2 Owners per subscription. Each Owner is a tenant-wide compromise risk; reducing the count reduces the blast radius of a phished credential.
azure-kv-public-networkKey Vaults with publicNetworkAccess=Enabled expose the management endpoint to the internet. Disable and configure private endpoints for the applications that need vault access.
azure-kv-rbac-modeRBAC authorization integrates Key Vault with PIM, conditional access, and central RBAC auditing. Legacy Access Policies are vault-local and can't be governed centrally.
azure-kv-soft-deleteSoft delete retains deleted vaults/keys for 90 days; purge protection blocks force-delete during that window. Together they protect against scenarios where attackers delete keys to lock out the owner.
azure-log-retentionWorkspace retention <90 days truncates data before most breach investigation windows. CIS recommends ≥90 days; PCI-DSS and HIPAA require at least 1 year of accessible logs.
azure-mcsb-assignedMCSB is Microsoft's canonical Azure security baseline. Assigning it at the subscription or management-group root gives continuous compliance scoring in Defender for Cloud.
azure-mysql-ssl-enforceMySQL Single Server: sslEnforcement should be Enabled. Flexible Server: require_secure_transport server parameter should be ON. Without these, clients can connect in plaintext.
azure-nsg-db-ports-internetDatabase ports (1433, 3306, 5432, 27017, 6379) open to *, Internet, or 0.0.0.0/0 expose databases to credential-stuffing, unauthenticated access (Redis default), and data exfiltration.
azure-nsg-overly-permissiveAny-protocol, any-source, any-port Allow rules defeat the principle of least connectivity and provide lateral-movement paths even when not directly internet-exposed.
azure-nsg-rdp-internetTCP/3389 open to *, Internet, or 0.0.0.0/0 exposes Windows RDP to the internet. Public RDP is a primary initial-access vector for ransomware.
azure-nsg-ssh-internetTCP/22 open to *, Internet, or 0.0.0.0/0 lets the world brute-force SSH. Use Bastion / VPN / IP allowlists instead.
azure-orphaned-disksManaged disks in the Unattached state are billed at full provisioned capacity while serving no workload, and still contain a complete readable copy of whatever the deleted VM held.
azure-orphaned-network-resourcesNetwork interfaces attached to no VM, public IPs attached to no resource, and network security groups attached to no subnet or NIC. Billed or reserved for nothing, and — in the NSG case — usually a rule set someone believes is in force.
azure-postgres-ssl-enforcePostgres Single Server: sslEnforcement should be Enabled. Flexible Server: require_secure_transport server parameter should be ON. Without these, clients can connect in plaintext.
azure-public-ip-inventoryCatalogs every public IP in scope and what resource it's attached to. Never fails — purely informational. These IPs are also fed into the external attack surface (Shodan/crt.sh) as seed inputs.
azure-sql-aad-adminSQL Servers without an AAD admin force clients onto local SQL auth, which doesn't support MFA / conditional access / centralized governance.
azure-sql-firewall-broadFirewall rules permitting 0.0.0.0 → 255.255.255.255 (all IPv4) or 0.0.0.0 → 0.0.0.0 (all Azure services) expose the SQL Server to anything on the internet or the entire Azure fleet.
azure-sql-tdeTDE encrypts data at rest with negligible perf impact. On by default for new databases; older ones may still have it off.
azure-sql-threat-protectionDefender for SQL detects SQL injection attempts, brute force, and anomalous access patterns. Requires Defender for Cloud's SQL plan.
azure-storage-anonymous-containersA container with publicAccess set to Blob or Container permits anonymous access at the container level. Effective access also depends on account-level anonymous-access permission and network restrictions; this setting alone does not prove internet readability.
azure-storage-blob-soft-deleteBlob soft delete protects against accidental and malicious deletion. Microsoft recommends ≥7-day retention; longer is better for ransomware recovery.
azure-storage-firewall-publicnetworkAcls.defaultAction = Allow means the storage firewall is open to any network. Set Deny with explicit allowlists or private endpoints.
azure-storage-min-tls-versionminimumTlsVersion below TLS 1.2 lets clients negotiate weaker cipher suites and breaks PCI-DSS / FedRAMP / most enterprise compliance baselines.
azure-storage-private-endpoint-coveragePrivate endpoints let storage accounts be reached only over the VNet, eliminating public network exposure. Coverage <50% indicates substantial public-surface storage; ≥80% is a hygiene target worth pursuing.
azure-storage-public-blob-accountWhen allowBlobPublicAccess is true, individual containers can opt into anonymous internet access. Disabling at the account level enforces the secure default across every container.
azure-storage-secure-transferStorage accounts with supportsHttpsTrafficOnly=false accept plaintext HTTP requests. Forces all REST API calls to use TLS when enabled.
azure-vm-disk-encryptionVM disks should be encrypted via encryptionAtHost (preferred) or Azure Disk Encryption (legacy). Default platform encryption protects only the underlying storage; per-VM controls protect against escape scenarios.
azure-vm-mde-coverageDefender for Endpoint provides EDR on the guest OS. Coverage below 80% indicates onboarding debt; below 50% means significant attack surface is unmonitored. With a Defender for Servers plan, Defender for Cloud installs the sensor on supported machines by default.
azure-vm-public-ipVMs with a directly attached public IP expose the host to the internet. Prefer Azure Bastion (for admin access) or App Gateway / LB with WAF (for app traffic) rather than direct public IP exposure.
azure-vm-stale-osVMs on EOL operating systems receive no vendor security patches. Migrate to a supported image or apply Microsoft Extended Security Updates (paid).
logging.alert-recipients-configuredLogs are useful only if someone reads them. Microsoft Defender ships high-value alerts (new forwarding rule, admin role elevation, suspicious forwarding activity) that go to nobody by default unless an admin sets email recipients. Untriaged alerts are equivalent to no detection.
logging.mailbox-audit-defaultMailbox auditing is the foundation for ALL post-incident investigation of an account compromise. Without it, you cannot tell what an attacker did inside a mailbox — when they signed in, what mail they read, what rules they created, what they deleted. Critical actions like UpdateInboxRules must be in the default owner audit set.
logging.service-health-notificationsMicrosoft sends service-health incidents, security advisories, and license/billing notifications to addresses on file in the tenant. If these default to the original signup contact (often a personal email of a long-departed admin), important messages — including Microsoft's own breach notifications to your tenant — get lost.
logging.unified-audit-logThe unified audit log records sign-ins, file accesses, admin actions, policy changes — everything you'd need to investigate an incident. Whether it's ingesting is an Exchange/Purview setting our read-only Graph access cannot read, so we surface it for one-command verification rather than guessing from unrelated Entra logs.
external.attack-surface-summaryRoll-up of every domain, IP, and exposed service Tenant Strike discovered from the outside-in view. Verify each entry corresponds to a known business system — anything unrecognized is a shadow-IT or decommissioned-but-still-on asset that warrants investigation.
external.cve-vulnerabilitiesShodan, a public index of internet-facing systems, lists the published vulnerabilities (CVEs) that match the software it saw on each address. Unless Shodan marks a match verified, it is inferred from that software and its version and has not been tested against the service. The same index is open to anyone, so an attacker can read the same list.
external.dns-integrityDNSSEC signs your DNS records so resolvers can detect tampering; CAA records restrict which certificate authorities may issue certificates for your domain. Both limit attacks that impersonate your domain.
external.domain-registrationAn expired domain takes email and your website offline at the same time, and lets someone else register it and receive your mail. A registrar transfer lock is a free setting that blocks one leg of a domain hijack.
external.exposed-admin-panelsWeb admin interfaces (phpMyAdmin, cPanel, Jenkins, Kibana, vCenter, etc.) should be accessible only from a trusted network or behind an identity-aware proxy. Public exposure invites credential stuffing and exploitation of the steady stream of CVEs these products ship.
external.exposed-databasesDatabases should always be private — behind a VPC/VNET, accessible only from the application tier. Public exposure represents either a misconfigured cloud instance or a legacy server that was never moved behind a firewall. Many database engines (Mongo, ES, Redis) ship with no authentication by default.
external.exposed-management-portsRemote-management protocols (RDP, SMB, WinRM, VNC), hosting control panels (cPanel, WHM, Control Web Panel, Webmin) and cleartext file transfer (FTP) should be reachable only through a VPN or zero-trust gateway. Direct internet exposure of these is the leading initial-access vector for ransomware and remote-access breaches.
external.lookalike-domainsAttackers register domains that resemble yours (character swaps, extra words, alternate TLDs) to send phishing and business-email-compromise mail that looks like it's from you. A lookalike with an MX record is infrastructure ready to send.
external.php-security-fixIn October 2026 the PHP project fixed two critical flaws that let anyone run code on a web server without signing in. This reads the PHP version a public website announces and says whether it predates the fix, or that the site runs PHP without showing which version.
external.reputationabuse.ch publishes blocklists of hostnames serving malware (URLhaus) and botnet command-and-control IPs (Feodo Tracker). If one of your own assets is listed, it has been compromised and is being used against others — and it will also get your mail and traffic blocked.
external.security-headersSecurity response headers (HSTS, X-Frame-Options / CSP, X-Content-Type-Options) harden your public web login pages against SSL-stripping, clickjacking, and MIME-confusion attacks.
external.security-txtA small text file at /.well-known/security.txt tells anyone who finds a security problem in your systems exactly how to reach you. Without one, reports go to a general inbox and often get missed.
external.shodan-flagged-hostShodan labels indexed hosts with tags such as compromised, malware, database, or ics. A flag on one of your own hosts is an independent signal that it's breached or exposing something it shouldn't.
external.subdomain-takeoverA subdomain whose CNAME points at a deleted cloud resource (S3 bucket, Azure web app, GitHub Pages site, etc.) can be re-registered by anyone, who then serves content — with valid TLS — on your own domain. Prime phishing and cookie-theft infrastructure.
external.tls-certificate-issuesTLS certificates that are expired, near-expiry, self-signed, or signed with weak algorithms cause user-facing errors or outages and erode trust.
external.tls-protocolDeprecated TLS/SSL protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1) are vulnerable to downgrade and cipher attacks, fail PCI-DSS, and are rejected by up-to-date browsers and API clients.
external.unsupported-softwareA version of Windows or Exchange Server that Microsoft has stopped supporting gets no fix for flaws found after that date. On a machine reachable from the internet, each new flaw stays open for good.
external.website-headersA website can tell a visitor's browser to always use an encrypted connection, to refuse being shown inside another site's frame, and not to guess a file's type. A home page sent without them leaves the browser on its looser defaults.
external.website-partsA website built on WordPress shows visitors which version it runs and which plugins it uses. WordPress.org says which versions later releases have replaced and which plugins it has closed, and a site that shows one of those is worth a look.
external.website-softwareA website can announce the software it runs on to every visitor. When that is a version its maker has stopped fixing, flaws found afterwards stay open unless the hosting company patches it itself. PHP, the Apache web server and Microsoft's IIS are the software judged today.
Reproduce it yourself
Tenant Strike's GraphReadOnlyClient (src/auth/graph.ts) exposes only GET. This manifest is regenerated on every build by scripts/build-graph-endpoints.ts, which fails the build if any write verb (post/patch/put/delete) is detected on a receiver typed as GraphReadOnlyClient. The list below is the complete set of Microsoft Graph endpoints Tenant Strike calls, with source-file references for line-level verification.
TypeScript AST walker (src/auth/graph-endpoint-extractor.ts) — resolves the receiver's type to GraphReadOnlyClient regardless of variable name. Catches aliases and `as any` casts that the prior regex-based extractor could have missed.Endpoint manifest · auto-extracted
/usersL161<dynamic>L48<dynamic>L49/groupsL44/groups/${String(read.rows[0].id)}/membersL59/admin/sharepoint/settingsL95/deviceManagement/managedDevicesL124/security/secureScoresL167/admin/serviceAnnouncement/healthOverviewsL215/auditLogs/directoryAuditsL261/reports/authenticationMethods/userRegistrationDetailsL60/users/${encodeURIComponent(upn)}L115/auditLogs/signInsL153/identity/conditionalAccess/policiesL206/servicePrincipalsL279/servicePrincipals/${encodeURIComponent(spId)}/appRoleAssignmentsL314/roleManagement/directory/roleDefinitionsL375/roleManagement/directory/roleAssignmentsL382/servicePrincipalsL149/oauth2PermissionGrantsL164/beta/reports/servicePrincipalSignInActivitiesL177/applicationsL197/usersL120/users/uL134/usersL134<dynamic>L68<dynamic>L69<dynamic>L70<dynamic>L21<dynamic>L26<dynamic>L31/users/${input.objectId}/transitiveMemberOf/microsoft.graph.directoryRoleL65/domainsL80/domainsL180/servicePrincipals/${id}L78/applications(appId='${sp.appId}')L103/directoryObjects/${id}L27/directory/deletedItems/${id}L31/users/${id}L45/servicePrincipalsL16/organizationL52/organization/${orgId}/branding/localizations/default/squareLogoL61/organization/${orgId}/branding/localizations/default/bannerLogoL62/organization/${orgId}/branding/localizations/default/squareLogoDarkL64/subscribedSkusL74/policies/adminConsentRequestPolicyL28/applicationsL37/servicePrincipals/${id}L26/servicePrincipals/${spId}/appRoleAssignmentsL54/directoryRolesL44/directoryRoles/${role.id}/membersL46/roleManagement/directory/roleEligibilityScheduleInstancesL53/servicePrincipalsL89/applicationsL123/servicePrincipals/${sp.id}/ownersL134/applications/${reg}/ownersL135/applicationsL240/servicePrincipalsL13/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')L133/servicePrincipalsL244/beta/reports/servicePrincipalSignInActivitiesL260/applicationsL335/servicePrincipals/${sp.id}/appRoleAssignmentsL364/policies/authorizationPolicyL57/deviceManagement/managedDevices/${d.id}/windowsProtectionStateL105/security/alerts_v2L55/deviceManagement/managedDevicesL79/deviceManagement/deviceCompliancePoliciesL89/deviceAppManagement/iosManagedAppProtectionsL105/deviceAppManagement/androidManagedAppProtectionsL115/usersL130/users/${u.id}/mailFolders/inbox/messageRulesL160/policies/authenticationMethodsPolicyL50/directoryRolesL267/directoryRoles/${gaRole.id}/membersL294/users/${m.id}L333/policies/conditionalAccessPoliciesL374/groups/${g}/transitiveMembersL429/policies/authenticationStrengthPoliciesL31/organizationL70/directoryRolesL401/users/${id}L418/groups/${id}L430/policies/identitySecurityDefaultsEnforcementPolicyL95/policies/conditionalAccessPoliciesL133/identity/conditionalAccess/namedLocationsL66/policies/authorizationPolicyL74/policies/deviceRegistrationPolicyL84/policies/authorizationPolicyL35/identityProtection/riskDetectionsL98/auditLogs/signInsL76/domainsL60/groups/${groupId}/membersL72/usersL133/directoryRolesL157/directoryRoles/${role.id}/membersL182/users/${m.id}L201/roleManagement/directory/roleEligibilityScheduleInstancesL228/users/${principalId}L255/auditLogs/directoryAuditsL207/identityProtection/riskyUsersL61/identityProtection/riskyUsersL76/users/${encodeURIComponent(u.id)}L325/policies/identitySecurityDefaultsEnforcementPolicyL16/usersL29/directoryRolesL38/directoryRoles/${gaRole.id}/membersL66/reports/authenticationMethods/userRegistrationDetailsL23/organizationL50/auditLogs/directoryAuditsL53/auditLogs/signInsL61/policies/crossTenantAccessPolicy/defaultL52/policies/crossTenantAccessPolicy/partnersL61/admin/sharepoint/settingsL109/test-deniedL138/usersL37/usersL41/subscribedSkusL64/admin/serviceAnnouncement/issuesL46/admin/serviceAnnouncement/messagesL50/oauth2PermissionGrantsL136/directoryRolesL211/directoryRoles/${role.id}/membersL222/roleManagement/directory/roleEligibilityScheduleInstancesL237/reports/authenticationMethods/userRegistrationDetailsL261/groups/${gid}/transitiveMembersL288/identityProtection/riskDetectionsL320/directoryRolesL389/directoryRoles/${role.id}/membersL401/usersL86/usersL90/subscribedSkusL104/domainsL129/users/${u.id}/mailFolders/inbox/messageRulesL150/subscribedSkusL728/security/secureScoresL31/security/secureScoreControlProfilesL67/deviceManagement/detectedAppsL46/deviceManagement/managedDevicesL49Azure Resource Manager · machine-verified read-only
The same automated build check covers our Azure code: every call we make to Azure is a read. We never change, create, or delete anything in your subscriptions.
${app.id}/config/web${app.id}/config/authsettingsV2<dynamic>/providers/Microsoft.ResourceGraph/resources/subscriptions/${subId}/providers/Microsoft.Security/pricings<dynamic>/subscriptions/${subId}/providers/Microsoft.Authorization/roleAssignments/subscriptions/${subId}/providers/Microsoft.Insights/diagnosticSettings/subscriptions/${subId}/providers/Microsoft.Security/autoProvisioningSettings<dynamic>/subscriptions/subscriptions/${sub.id}/providers/Microsoft.Authorization/roleAssignments?$filter=atScope()/subscriptions/${sub.id}/providers/Microsoft.Authorization/denyAssignmentsThe one POST in the list is Azure's Resource Graph query endpoint — Azure requires POST there only because the (read-only) query is too long to fit in a URL. Nothing is changed by it, and our build check treats it as the single documented exception.
Comfortable with how we work?
No write scopes, no agents, and a setup that takes a few minutes. See what your tenant looks like to an attacker.