TenantAtlas/docs/strategy/domain-coverage.md

Domain Coverage Map

Canonical classification of Microsoft domains for TenantPilot platform planning. This document defines which domains receive which product primitives and why.

Last updated: 2026-03-17

---

Purpose

TenantPilot covers multiple Microsoft domains, but not all domains fit the same product model. This document establishes a stable classification so that new feature ideas, spec candidates, and roadmap entries can be evaluated against a shared understanding of how each domain maps to TenantPilot's capabilities.

The goal is not to model "all of Microsoft 365" uniformly. The goal is to build a coherent governance platform by separating domains into distinct product classes:

1. First-class Policy Domains — domains with explicit policy objects, settings, or rules that fit TenantPilot primitives such as inventory, versioning, diff, baseline, drift, search/explorer, findings, exceptions, and review-linked evidence.

2. Governance / Attestation Domains — domains centered on ownership, approvals, scheduled reviews, access attestation, lifecycle decisions, renewal/expiry workflows, and exception/risk acceptance linkage. These are not primarily configuration drift domains.

3. Evidence / Signal Domains — domains that primarily provide posture, risk, audit, or telemetry signals. TenantPilot ingests, historizes, correlates, reports, and alerts on these. They are not primary policy objects.

---

Strategic note

TenantPilot is a governance, audit, and review platform for Microsoft tenant operations. It is not a generic Microsoft 365 admin mirror and not a second RMM. It should not pretend that all Microsoft domains fit one universal primitive.

Compliance support means readiness, evidence, and governance — not formal certification claims. This domain map does not alone make customers compliant with BSI, NIS2, ISO 27001, or any other framework. It defines where TenantPilot provides deep governance coverage and where it acts as a review, evidence, or reporting layer instead.

---

1. First-class Policy Domains

These are domains where TenantPilot can provide the full configuration governance stack: inventory, snapshot/versioning, compare/diff, baseline, drift detection, search/explorer, findings/exceptions, and review-linked evidence.

Core now

Intune Configuration

Includes Settings Catalog, Device Configuration/Templates, Endpoint Security, Compliance Policies, and App Protection Policies.

Intune exposes large, explicit configuration surfaces with searchable and assignable settings. The Settings Catalog alone contains thousands of entries with continuous additions. Endpoint Security, Compliance, and App Protection are distinct policy families with clear assignment semantics. This is the clearest match for TenantPilot's existing backup, versioning, drift, and explorer model.

Entra Conditional Access

Conditional Access is Microsoft's Zero Trust policy engine. Policies are built from explicit conditions and access controls with clear target resources. This is a strong fit for inventory, review, baseline-style governance, and explainability, even though its semantics differ from device settings.

Entra Authentication Methods

Authentication Methods Policy is the recommended way to manage which authentication methods users or groups can use, including modern and passwordless methods. This is a strong policy domain for governance and review.

Next

Teams Policies

Includes meeting policies, messaging policies, app setup policies, and other Teams policy families with assignment semantics. Teams has explicit policy families and documented assignment behavior, making it a strong secondary policy domain after Intune and Entra core security controls.

Entra Role Definitions and Assignments

Includes built-in roles, custom role definitions, and role assignments. Microsoft Entra supports both built-in and custom roles with a clear separation between definitions and assignments. This is central to governance and should become a first-class policy/governance surface for identity administration.

SharePoint Tenant-level Sharing and Access Settings

SharePoint and OneDrive external sharing are governed at both organization and site level, with the organization-level setting acting as the upper boundary. These tenant-level settings are too important for governance and audit readiness to defer beyond the next wave.

Later

Cross-tenant Access / External Collaboration Settings

Cross-tenant access is a real policy domain with inbound and outbound controls for B2B collaboration and direct connect. It is more specialized and should follow the core identity and device governance surfaces.

App Consent Policies

Entra supports built-in and custom app consent policies that control when consent can be granted. Strategically important but narrower than the core policy domains above.

Purview DLP Policies

Purview DLP is a real policy domain, but significantly more complex than Intune or Conditional Access. Policies span many components, locations, conditions, and actions. It should be treated as a later premium governance domain, not an early uniform extension.

Selective / not first-class early

Exchange Authentication and Mail Flow Hardening

Exchange remains relevant for governance, but it should be handled selectively rather than as an early first-class domain. Basic Authentication is already disabled across tenants, so this area is less suitable as a major new core pillar than Intune, Conditional Access, or SharePoint tenant sharing. Selective coverage of mail flow rules and remaining auth hardening checks is appropriate without committing to deep first-class platform support.

---

2. Governance / Attestation Domains

These are domains where TenantPilot focuses on ownership, review schedules, approval and attestation, status and overdue visibility, exceptions/risk acceptance linkage, evidence and reporting, and alerts/renewal workflows. These domains are not primarily about configuration drift.

Core now

Entra Access Reviews

Access Reviews are designed to control group membership and application access for governance, risk, and compliance purposes, including recurring reviews and policy exception review scenarios. This is a direct match for TenantPilot's governance and evidence direction.

Privileged Identity Management (PIM)

PIM manages, controls, and monitors privileged access, including limiting standing administrator access and reviewing privileged assignments with time- and approval-based activation. This is a first-class governance and attestation domain.

Next

Enterprise App / Service Principal Governance

Includes application inventory, high-privilege permissions visibility, expiring app credentials, expiring service principal credentials, and review/renewal workflows. Microsoft Entra provides concrete recommendations for expiring application and service principal credentials, making this a strong governance surface for alerts, review, renewal, exceptions, and customer-facing evidence.

Entitlement Management

Includes access packages, catalogs, request workflows, approvals, reviews, and expirations. Entitlement Management automates access request workflows, assignments, reviews, and expiration at scale. It is a natural extension of TenantPilot's review and attestation layer.

Later

Lifecycle Workflows

Lifecycle Workflows automate user lifecycle processes across joiner, mover, and leaver phases. Strategically relevant but fits better as a later governance automation layer than as an initial core domain.

Terms of Use

Terms of Use policies are relevant to access governance and user attestation, especially when enforced with Conditional Access. Narrower than Access Reviews or PIM, but suitable for inventory, status, and review pack evidence.

Admin Consent Workflow

Admin Consent Workflow is a governance queue and decision mechanism for applications requiring admin consent. Valuable but more focused than the broader governance domains above.

Cross-cutting governance capability

Guest / External Identity Lifecycle

Guest and external identity lifecycle should be treated as a cross-cutting capability, not necessarily as a completely separate top-level domain. It spans Access Reviews (reviewing guest group memberships), Entitlement Management (access packages with reviews and expiration for external users), Cross-tenant Access (inbound/outbound collaboration controls), and later Lifecycle Workflows (leaver automation for external identities). Microsoft's governance model for external access is distributed across these features rather than isolated into one single product object.

---

3. Evidence / Signal Domains

These are domains where TenantPilot primarily ingests, normalizes lightly, historizes, correlates, reports, and alerts. They are essential for posture, audit, and review packs, but they are not the primary configuration or attestation objects.

Core now

Microsoft Secure Score

Secure Score is a numerical security posture summary based on configurations, user behavior, and other security-related measurements. Ideal for history, trends, dashboards, and review reporting.

Entra Sign-in and Audit Logs

Sign-in logs and audit logs provide activity records used for troubleshooting, compliance, and understanding changes across users, groups, and applications. They are foundational evidence sources.

Next

Entra ID Protection

ID Protection detects, investigates, and helps remediate identity-based risks. Those risk signals feed tools such as Conditional Access. Highly valuable as a risk and evidence signal domain.

Defender Vulnerability Management

Defender Vulnerability Management provides an exposure score reflecting how vulnerable the organization is to cyber threats. A strong evidence domain for device risk, remediation progress, and customer review packs.

Backup Signals

Backup belongs in the evidence layer as operational assurance, not as a normal policy domain. Microsoft 365 Backup is a distinct capability with backup policies and restore-oriented architecture, which supports ingesting success/failure and protection state as review evidence.

Later

Purview Unified Audit

Purview Audit provides integrated auditing across many Microsoft services. Valuable for investigations, compliance obligations, and long-term evidence. Strategically strong but can follow the earlier evidence foundations.

Defender for Cloud Apps

Defender for Cloud Apps is a broad SaaS protection and visibility platform with CASB, SSPM, threat protection, and app-to-app protection capabilities. Relevant but broader than the initial evidence stack TenantPilot needs first.

---

Coverage Priorities

Core now

• Intune Configuration (Settings Catalog, Device Configuration/Templates, Endpoint Security, Compliance, App Protection)
• Entra Conditional Access
• Entra Authentication Methods
• Entra Access Reviews
• Privileged Identity Management (PIM)
• Microsoft Secure Score
• Entra sign-in and audit logs

Next

• Teams Policies
• Entra role definitions and assignments
• SharePoint tenant-level sharing and access settings
• Enterprise App / Service Principal Governance
• Entitlement Management
• Entra ID Protection
• Defender Vulnerability Management
• Backup signals

Later

• Cross-tenant access / external collaboration settings
• App consent policies
• Purview DLP policies
• Lifecycle Workflows
• Terms of Use
• Admin Consent Workflow
• Purview unified audit
• Defender for Cloud Apps

---

Product Interpretation Rules

Rule 1 — First-class policy domain criteria. A domain becomes a first-class policy domain only if it has stable policy objects, meaningful scope/assignment semantics, and enough customer value to justify inventory, versioning, compare, baseline, drift, and explorer UX.

Rule 2 — Governance / attestation domain criteria. A domain becomes a governance/attestation domain when the core operator question is about review, ownership, approval, access lifecycle, expiry, or exceptions rather than about configuration compare.

Rule 3 — Evidence / signal domain criteria. A domain becomes an evidence/signal domain when TenantPilot's main value is ingesting and explaining posture, risk, or audit data rather than owning the configuration object itself.

Rule 4 — No universal primitive assumption. TenantPilot should avoid pretending that all Microsoft domains fit the same primitive. The platform should stay explicit about whether a feature surface treats a domain as a policy object, a review/attestation workflow, or an evidence/signal feed. That separation is what keeps the product extensible instead of turning it into a generic M365 admin mirror.

Rule 5 — Classification before planning. When a new Microsoft domain is proposed for TenantPilot, it must be classified into one of the three domain classes before it is added to the roadmap or to spec-candidates. The first question is always: "Which domain class does it belong to?" Only after that should the team decide which product primitives apply, how deep coverage should go, and whether it belongs in core, next, or later.

---

Practical Implication for Roadmap Planning

When evaluating a new feature idea or domain expansion:

1. Classify the domain. Determine whether it is a policy domain, a governance/attestation domain, or an evidence/signal domain. If it does not fit cleanly, it may span multiple classes — document which primitives apply to which aspect.

2. Select the right primitives. Policy domains get the full configuration governance stack. Governance domains get ownership, review, attestation, and exception workflows. Evidence domains get ingestion, historization, correlation, and reporting. Do not force a domain into primitives that do not fit its structure.

3. Prioritize by customer value and extractability. Core-now domains are those where TenantPilot already has strong foundations or where customer demand is immediate. Next domains are those with clear product fit but lower urgency or higher integration effort. Later domains are those that are strategically relevant but can wait for the platform to mature.

4. Keep provider boundaries explicit. Each domain's integration logic should remain domain-specific. Do not build universal abstractions that pretend all Microsoft domains share the same schema or the same semantic model.

5. Reference this document. Roadmap entries, spec candidates, and feature proposals should reference the domain classification established here. If a domain's classification needs to change, update this document first.