How TenantSentinel Scores Your Tenant
Every number in a TenantSentinel report is derived from your live Microsoft 365 configuration, scored against published security frameworks, and calculated using a documented formula. This page explains exactly how that works.
TenantSentinel grew out of five years of hands-on Microsoft 365 security work — not a research project or a vendor roadmap, but real client engagements. After working through tenant audits with over 100 organizations, a pattern emerged: the same gaps kept appearing, the same attacks kept succeeding, and the existing tools kept falling short in the same ways.
Microsoft Secure Score is useful, but it’s a checklist. CIS benchmarks are thorough, but they’re a blanket — they tell you what best practice looks like in the abstract, not what the actual risk looks like in your specific tenant. What was missing was something that could look at a tenant the way a security practitioner looks at it: understanding which gaps matter most given the actual configuration, not just which boxes are unchecked.
The scoring methodology, the weighted pillars, the severity penalties — these aren’t theoretical. They reflect what I’ve seen work and what I’ve seen fail across five years of managing M365 security for clients. Every risk scenario in the tool corresponds to something I’ve encountered in the real world, including attacks that succeeded and the defenses that prevented the next one. That’s what TenantSentinel is trying to be: the assessment a security-minded M365 practitioner would run by hand, automated and repeatable.
Data Collection
TenantSentinel reads your Microsoft 365 configuration directly through the Microsoft Graph API using application permissions and certificate-based authentication. All permissions are read-only — the tool cannot modify, create, or delete anything in your tenant. No data is transmitted to TenantSentinel servers during a scan; the assessment runs locally on the machine where the desktop app is installed, and the resulting report is a self-contained HTML file that stays on your machine.
The following data is collected and analyzed:
Per-user MFA registration state, authentication methods, sign-in activity, and license assignments. Used to measure MFA coverage and phishing-resistant authentication adoption.
All CA policy definitions: state, conditions, grant controls, session controls, and user/group exclusions. Used to evaluate coverage of users, apps, and enforcement posture.
Directory role assignments for Global Administrator, Privileged Role Administrator, Exchange Administrator, and other high-privilege roles. Checks for PIM usage, dedicated admin accounts, and role concentration.
SSPR enablement, Microsoft Secure Score, tenant display name, and licensing assignments. Secure Score is reported as context but is not used as an input to TenantSentinel’s own scoring.
Enterprise app registrations and service principal permissions (OAuth2 grants and app role assignments). Filtered to exclude Microsoft first-party apps; third-party and custom apps are classified by permission risk level.
SKU assignments and per-user license utilization. Used to identify over-provisioned licenses, duplicate capability coverage, and estimated cost optimization opportunities. Not used in security scoring.
Executive Score — Weights & Formula
The Executive Score is a 0–100 index representing your overall Microsoft 365 security posture across three pillars: identity protection, access control, and privileged security. Each pillar is scored independently (0–100) and then combined using fixed weights that reflect the relative attack surface each control area represents.
Executive Score = Base Score − Severity Penalties + Maturity Bonuses
clamped to [0, 100]
| Pillar | Weight | What it measures | Why this weight |
|---|---|---|---|
| Access Control Conditional Access |
Coverage of Conditional Access policies across users, apps, and sign-in conditions. Evaluates whether CA policies exist, are enabled, enforce MFA or device compliance, and cover the tenant’s full app surface — including which published SaaS apps remain unprotected. | Conditional Access is the single broadest control available in Microsoft 365. A well-configured CA policy can protect every user and every app simultaneously. Gaps here have tenant-wide blast radius, which is why it carries the largest weight. | |
| Identity Protection MFA & Authentication |
Percentage of licensed users with MFA enforced, adoption of phishing-resistant methods (FIDO2, Windows Hello, certificate-based), and MFA coverage for administrative accounts specifically. | Credential theft is the most common initial access vector in M365 breaches. MFA prevents the majority of password-based attacks. It carries the second-largest weight because even with no CA policies, per-user MFA enforcement provides meaningful protection. | |
| Privileged Security Privileged Roles |
Number and concentration of privileged role assignments, use of dedicated admin accounts (separate from daily-use accounts), admin account MFA registration, Global Administrator count, and Privileged Identity Management (PIM) adoption. | Privileged role compromise is high-impact but typically affects a smaller number of accounts than a broad MFA gap. The weight reflects that the exposure is real and serious, but narrower in scope compared to identity and access controls. |
How Each Pillar is Scored
Starts at 0. Points are awarded for each enabled CA policy proportionally based on how many users and published apps it covers. Policies are evaluated against a catalog of Microsoft 365 and common enterprise SaaS apps. Policies that apply to all apps (“All cloud apps”) receive full credit. Policies that exclude large groups of users, or that are in report-only mode, receive partial or no credit.
Calculated as the percentage of enabled licensed users with MFA enforced or registered, weighted by authentication method strength. Phishing-resistant methods (FIDO2, Windows Hello for Business, certificate-based auth) are counted at higher value than SMS or authenticator app. A tenant where every user has MFA and a substantial portion uses phishing-resistant methods scores near 100.
Starts at 100 and is penalized based on findings: too many Global Administrators, admins using their admin account as a daily-use account, privileged accounts without MFA registration, and missing PIM enrollment. The more concentrated and unprotected the privileged role surface, the lower the score.
Severity Penalties & Maturity Bonuses
The base weighted score can be adjusted by a set of explicit penalties and bonuses. These are applied after the three pillar scores are combined and represent conditions severe enough to warrant special attention or recognition beyond what the weighted average captures.
All penalties and bonuses are documented here. None are hidden or implied.
Severity Penalties reduce score
| Condition | Penalty | Rationale |
|---|---|---|
| Any pillar scores below 25 (Identity, Access, or Privileged) | −15 pts per pillar | A pillar below 25 represents a near-total failure of that control domain. The weighted average alone underrepresents how dangerous this is — a 0-point CA score combined with a high MFA score would still yield an acceptable aggregate. This penalty prevents the weighted average from masking a catastrophic gap. |
| Privileged users explicitly excluded from MFA policies | −5 pts per user capped at −20 pts |
A privileged account in a CA policy exclusion list is a high-value target without MFA protection. Break-glass (emergency access) accounts are intentionally exempt from this penalty, as their exclusion is expected and necessary. Only non-break-glass privileged users in exclusion lists are penalized. |
| Crown jewel applications not protected by any CA policy | −10 pts | Certain apps — Exchange Online, SharePoint/OneDrive, Microsoft Teams, Azure Management Portal — are treated as crown jewels because their compromise has outsized organizational impact. If any of these remain completely uncovered by a CA policy, a flat penalty is applied regardless of overall CA score. |
| No CA policy blocking legacy authentication protocols | −8 pts | Legacy authentication (Basic Auth, SMTP AUTH, IMAP, POP3) cannot enforce MFA and is a well-documented attack path used in password spray campaigns. Microsoft has blocked Basic Auth for most M365 services, but gaps remain. Absence of a policy explicitly blocking legacy auth warrants a standalone penalty. |
Maturity Bonuses increase score
| Condition | Bonus | Rationale |
|---|---|---|
| 50% or more of users using phishing-resistant MFA (FIDO2, Windows Hello, certificate-based) | +5 pts | Standard MFA (SMS, authenticator app) is vulnerable to real-time phishing, SIM swapping, and MFA fatigue attacks. Phishing-resistant methods eliminate these vectors entirely. Reaching 50% deployment represents a deliberate organizational investment in stronger identity assurance beyond the baseline. |
| Privileged user ratio below 1% of total users | +3 pts | Least-privilege is a core security principle. Keeping the ratio of privileged accounts to total users very low indicates that role assignments are being managed actively rather than granted freely. This bonus rewards explicit hygiene, not just the absence of violations. |
| All enabled CA policies enforce MFA | +5 pts | When every active CA policy requires MFA as a grant control, the tenant achieves defense in depth — there is no enabled policy path that grants access without an authentication challenge. This is distinct from coverage (which apps are protected) and represents enforcement consistency across the full CA ruleset. |
Rating Thresholds
The final Executive Score maps to one of four qualitative ratings. These thresholds are fixed and applied consistently across all tenants.
| Score range | Rating | Meaning |
|---|---|---|
| 80 – 100 | Healthy | Core controls are well-implemented. MFA is broadly deployed, CA policies cover the majority of the app surface, and privileged accounts are actively managed. Remaining gaps are likely refinements rather than fundamental exposures. |
| 55 – 79 | Needs Attention | Meaningful controls exist but significant gaps remain. A motivated attacker would find viable paths — unprotected apps, accounts without MFA, or over-provisioned admin roles. Remediation should be prioritized, particularly for high-severity findings. |
| 25 – 54 | At Risk | Foundational controls are missing or ineffective. The tenant is measurably exposed to common attack patterns including credential theft, phishing, and privilege escalation. Immediate remediation of critical findings is warranted. |
| 0 – 24 | Critical | One or more control domains have effectively failed. The tenant has minimal protection against common attacks. This rating triggers automatic critical alerts calling out the specific failures. Remediation should be treated as urgent. |
The same four thresholds apply to individual pillar scores (Identity, Access, Privileged), allowing you to identify which specific control domain is dragging the overall score down. A “Healthy” overall score can coexist with an “At Risk” pillar if the other two pillars are strong enough to compensate in the weighted sum.
Compliance Framework Mapping
TenantSentinel maps each risk scenario and baseline policy gap to one or more controls from four published compliance frameworks. These mappings are included in every Executive Dashboard report on the Compliance Mapping tab. They allow security teams to connect individual findings to the specific control requirements their organization must satisfy.
The Center for Internet Security publishes a vendor-aligned benchmark specifically for Microsoft 365 environments. TenantSentinel v6.0.x aligns to Benchmark version 6.0.1, which covers Entra ID (Azure AD), Exchange Online, SharePoint, Teams, and M365 Defender. This is the primary framework for mapping, as it is purpose-built for the platform being assessed.
NIST Special Publication 800-171 defines requirements for protecting Controlled Unclassified Information (CUI) in non-federal systems. Revision 3 (finalized 2024) is the current version. Identity and access control requirements in 800-171 overlap substantially with the MFA and CA controls TenantSentinel evaluates, making it a natural secondary mapping for organizations with federal contracts or DFARS/CMMC compliance requirements.
The AICPA’s Trust Services Criteria (TSC) underpin SOC 2 audits. The access control and authentication requirements in Common Criteria (CC6.x series) map directly to the controls TenantSentinel evaluates — particularly CC6.1 (logical access controls), CC6.3 (role-based access), and CC6.6 (boundary controls). Organizations pursuing or maintaining SOC 2 Type II certification can use these mappings to identify M365 configuration gaps relevant to their audit scope.
The HIPAA Security Rule requires covered entities and business associates to implement safeguards for electronic Protected Health Information (ePHI). Authentication (§164.312(d)), access control (§164.312(a)(1)), and transmission security (§164.312(e)(1)) requirements align with the identity and access controls evaluated in TenantSentinel’s Executive Dashboard. Included for healthcare organizations using Microsoft 365 as part of their covered systems.
Example mappings
| TenantSentinel finding | CIS M365 v6.0.1 | NIST SP 800-171 Rev 3 |
|---|---|---|
| Users without MFA enforcement | 5.2.2.1 — Ensure MFA is enabled for all users in administrative roles 5.2.2.2 — Ensure MFA is enabled for all users |
03.05.03 — Employ multifactor authentication for privileged and non-privileged accounts |
| Legacy authentication not blocked | 5.2.2.3 — Ensure legacy authentication is blocked via Conditional Access | 03.13.01 — Monitor, control, and protect communications at external system boundaries |
| Users excluded from security policies | 5.2.2.2 — Ensure MFA is enabled for all users 5.2.2.1 — Ensure MFA is enabled for administrative roles |
03.01.01 — Limit system access to authorized users 03.01.02 — Limit access to permitted transaction types |
| No managed device requirement | 5.2.2.9 — Ensure a managed device is required for authentication | 03.13.06 — Deny network communications by default, allow by exception 03.04.01 — Establish and maintain baseline configurations |
Assessment Module Scoring
Licensed add-in modules extend TenantSentinel’s coverage to Device management, SharePoint, Exchange, Copilot for Microsoft 365, and Teams. Each module produces its own 0–100 score using dimension-weighted scoring specific to that workload. Module scores are independent of the Executive Score.
All module assessments follow the same principle: dimensions that represent broader attack surface or higher breach impact carry higher weights.
Device Assessment
| Dimension | Weight | What it evaluates |
|---|---|---|
| Compliance | Percentage of enrolled devices meeting the tenant’s compliance policies (encryption, password, OS version requirements) as reported by Intune. | |
| Encryption | BitLocker (Windows) and device encryption state across the device fleet. Unencrypted devices are a physical theft and data loss risk independent of network controls. | |
| OS Currency | Percentage of devices running a supported, current OS version. End-of-life OS versions no longer receive security patches and cannot be made compliant regardless of policy. | |
| Stale Devices | Devices not seen in Intune for an extended period. Stale device records suggest inventory hygiene issues and potential orphaned registrations that could be exploited. |
SharePoint Assessment
Adoption metrics are collected and displayed but carry zero weight in the SharePoint score. Low adoption is not a security signal.
| Dimension | Weight | What it evaluates |
|---|---|---|
| Storage Health | Site collection storage utilization relative to allocated quotas. Sites approaching or exceeding quota limits introduce availability and business continuity risk. | |
| Sharing Risk | External sharing settings, guest user ratio, and links shared externally. Over-permissive sharing is the primary SharePoint data exfiltration vector. Guest severity is scaled proportionally to the tenant’s licensed user count, not a fixed threshold. | |
| Dormancy | Sites and OneDrive accounts with no activity in the past 180 days. Dormant sites often accumulate stale content with permissions that were never cleaned up. |
Exchange Assessment
| Dimension | Weight | What it evaluates |
|---|---|---|
| Mailbox Health | Mailbox quota utilization, inactive mailboxes, and archive health. Full or unarchived mailboxes affect both availability and legal hold capability. | |
| Security Posture | Org-wide Exchange security controls: SMTP AUTH state, modern authentication enforcement, mailbox auditing enablement, and external email forwarding policy. Evaluated at the tenant level, not per-mailbox. | |
| Activity | Active vs. inactive mailbox ratio based on recent send/receive activity. High rates of inactive mailboxes suggest licensing waste and potential orphaned accounts that should be deprovisioned. | |
| Forwarding Risk | Per-mailbox forwarding rules configured to send email externally. External auto-forwarding is a primary data exfiltration technique following Business Email Compromise (BEC). Penalties are applied per forwarding rule found. |
Copilot for Microsoft 365 Assessment
| Dimension | Weight | What it evaluates |
|---|---|---|
| Oversharing Risk | SharePoint and OneDrive sharing settings in the context of Copilot access. Copilot surfaces content that users have access to — overly permissive sharing means Copilot can surface sensitive content to users who should not see it. | |
| Information Protection | Microsoft Purview sensitivity label deployment and policy coverage. Labels allow Copilot to respect classification boundaries and prevent responses that expose labeled content to unauthorized users. | |
| External Sharing Controls | Tenant-level controls restricting how Copilot output can be shared externally. Weak controls allow AI-generated summaries of sensitive content to leak outside the organization. | |
| Security Configuration | Copilot-specific tenant settings: plugin access controls, web search enablement, and logged-in user scope restrictions. These controls limit what Copilot can access and what it can do on behalf of users. |
Teams Assessment
| Dimension | Weight | What it evaluates |
|---|---|---|
| Guest Access | Guest access configuration at the tenant and team level, including whether guests can access channel files, initiate conversations, and bypass meeting lobby controls. External access carries the highest weight because it represents direct exposure outside the tenant security boundary. | |
| App Security | Third-party Teams app installation policies and which apps have been granted permission in the tenant. Unreviewed apps with broad permissions represent a supply-chain risk within the Teams environment. | |
| Config Hygiene | Teams messaging policies (e.g. external domain federation), meeting settings (recording policies, lobby bypass), and team ownership health (orphaned teams, single-owner teams). | |
| Data Exposure | Channel types allowed (public vs. private vs. shared), file sharing settings within Teams, and meeting recording retention. Uncontrolled data paths within Teams can lead to unintended data persistence and exposure. |
What This Assessment Does Not Cover
Being explicit about scope is as important as being explicit about methodology. TenantSentinel does not assess the following:
Firewall configuration, on-premises Active Directory, VPN settings, EDR/antivirus deployment, and physical security controls are out of scope. TenantSentinel evaluates Microsoft 365 cloud configuration only.
TenantSentinel is a configuration assessment tool, not a SIEM or threat detection platform. It does not analyze sign-in logs for anomalies, detect active intrusions, or identify in-progress attacks. Use Microsoft Defender for Identity, Sentinel, or an equivalent tool for threat detection.
TenantSentinel does not scan the contents of SharePoint libraries, mailboxes, Teams messages, or OneDrive files. It evaluates whether Purview sensitivity labels and policies are configured — not whether they have been applied to specific documents.
Findings are based on configuration state, not empirical testing of whether a vulnerability is actively exploitable in your specific environment. A finding labeled “Critical” means the configuration creates a known-high-risk exposure — not that an attack has been demonstrated against your tenant.
Compliance framework mappings in TenantSentinel reports are provided to aid remediation prioritization. They do not constitute a compliance audit, gap assessment, or certification. Formal determinations under CIS, NIST, SOC 2, HIPAA, or any other framework require an independent qualified assessor.
Questions about this methodology? Contact us — we’re happy to walk through how a specific finding was calculated.
Ready to run your own assessment? Get free access and see your tenant’s score in about 10 minutes.