Asset Inventory

A complete asset inventory is the prerequisite for every protection, monitoring, and compliance capability in this guide. You cannot label what you haven't found, cannot apply compliance policies to unmanaged devices, and cannot govern cloud apps you don't know exist. Asset inventory in Microsoft 365 spans three domains: data, devices, and cloud applications.

---

Data Asset Inventory

Content Explorer (Cloud Data)

Content Explorer is found in the Purview compliance portal under Data classification → Content Explorer. It shows all labeled content across Exchange, SharePoint, OneDrive, and Teams, searchable by label, sensitive information type (SIT), or location. The view displays item counts per label per location, which is useful for tracking auto-labeling coverage over time.

The display is limited to one million items. For volume reporting beyond that threshold, use Activity Explorer.

Access requires the Content Explorer Content Viewer or Content Explorer List Viewer role. Assign them deliberately and to a limited audience: they grant read access to actual file content.

Activity Explorer (Labeling Activity)

Activity Explorer is found under Data classification → Activity Explorer. It shows labeling events over time: label applied, label changed, label removed, DLP policy matches, and endpoint file events.

To track auto-labeling coverage progress, filter by Label applied combined with Auto-labeling as the activity source. This shows how many files were labeled by service-side policies versus user-applied labels, which is the primary progress metric during a labeling rollout.

On-Premises Data (Purview Scanner)

The Purview Information Protection Scanner runs on a Windows Server node and scans on-premises file shares and SharePoint Server sites. Results are stored in a SQL Server database. The portal shows summary counts, but per-file detail requires a direct SQL query.

For auditors requiring per-file evidence, query the SQL database directly. See Information Protection Scanner for SQL query examples.

Structured Data (Purview Data Map)

For data replicated into Azure SQL, Azure Synapse, or other databases from ERP, CRM, or HRIS systems, the Purview Data Map extends asset inventory to tables and columns. It registers the data source as a cataloged asset and classifies sensitive columns (bank account numbers, SSNs, PII) using the same SIT engine as M365.

See Structured Data Governance for configuration steps.

---

Device Asset Inventory

Two overlapping inventories serve different purposes for auditors and operations teams.

Entra Device Inventory (Identity Plane)

Access via the Entra admin center under Devices → All devices (portal.azure.com or portal.azure.us for GCC High).

This inventory records every device that has registered or joined the tenant: broader scope than Intune. Key fields include: device name, OS and version, join type (Entra Joined, Hybrid Entra Joined, or Entra Registered), compliance state (a single pass/fail badge reported from Intune), registered owner, and last sign-in.

This inventory does not contain hardware specs, software inventory, or per-policy compliance detail. Scope includes BYOD devices that registered via Entra (for example, for Entra MFA) but were never enrolled in Intune.

To export: Devices → Download (CSV): provides the full device list with all fields.

What it answers for auditors: What devices have an identity in this directory? Are any stale (last sign-in greater than 90 days)? What is the join type distribution?

Intune Device Inventory (Management Plane)

Access via the Intune admin center under Devices → All devices (endpoint.microsoft.com or endpoint.microsoft.us for GCC High).

Scope is limited to devices enrolled for Intune management: narrower than Entra but far richer per device. Key fields include: manufacturer, model, serial number, IMEI/MEID for mobile devices, RAM, storage, CPU, OS version, last check-in, compliance state, enrolled date, primary user, encryption status, and Intune management profile.

Software inventory is available per device under Devices → [Device] → Discovered apps, which lists all installed applications with version numbers.

To export: Devices → Export (CSV) for the hardware inventory; per-device Discovered apps export for software inventory.

What it answers for auditors: Are all managed devices encrypted? Are OS versions current? What applications are installed on managed devices? When did each device last check in?

The Gap Between Entra and Intune

Devices present in Entra but absent from Intune represent unmanaged endpoints with directory identities, the highest-risk category. These devices can authenticate against M365 resources without being subject to compliance policies.

To identify the gap:

# Connect to both services
Connect-MgGraph -Scopes "Device.Read.All","DeviceManagementManagedDevices.Read.All" -Environment USGov

# Entra device IDs
$entraDevices = Get-MgDevice -All | Select-Object -ExpandProperty DeviceId

# Intune device IDs (azureADDeviceId maps to Entra DeviceId)
$intuneDevices = Get-MgDeviceManagementManagedDevice -All | Select-Object -ExpandProperty AzureAdDeviceId

# Devices in Entra but not Intune
$entraOnly = $entraDevices | Where-Object { $_ -notin $intuneDevices }
Write-Host "$($entraOnly.Count) devices registered in Entra but not enrolled in Intune"

Remediation: require Intune enrollment as a Conditional Access grant control for all resource access.

---

Cloud Application Asset Inventory

Defender for Cloud Apps: Shadow IT Discovery

Microsoft Defender for Cloud Apps (MDA) discovers all cloud apps accessed from managed endpoints by analyzing DNS queries and network traffic forwarded from Defender for Endpoint.

Access via security.microsoft.com (or security.microsoft.us for GCC High) under Cloud Apps → Cloud Discovery → Dashboard.

Each discovered app shows its risk score (0–10), user count, traffic volume, and whether it has been marked as sanctioned or unsanctioned. The Cloud App Catalog contains risk assessments for over 31,000 apps, each scored on security, compliance, and legal dimensions.

Establishing the sanctioned app list:

1. Review discovered apps sorted by user count.
2. Mark IT-approved apps as Sanctioned: these form the baseline allowed list.
3. Mark prohibited apps (personal storage, unapproved AI tools) as Unsanctioned: MDA can generate a block list exportable to proxy or firewall for enforcement.

Microsoft Entra Application Registration Inventory

Access via the Entra admin center under Applications → App registrations (all applications) and Enterprise applications.

• App registrations: first-party apps your organization has registered: service principals for automation, custom apps, and integrations.
• Enterprise applications: all apps, first and third party, that have been granted access to the tenant, including OAuth consent grants.

To export: each blade has a Download option for CSV.

OAuth consent grant audit:

Overprivileged OAuth apps granted permissions such as Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All represent a significant risk vector. Review these quarterly using the App Governance dashboard in Defender for Cloud Apps. See Threat Defense for App Governance alert configuration.

---

Asset Inventory: Compliance Control Mapping

GCC High (CMMC)

CMMC Level 2 does not have a dedicated asset inventory control family, but asset inventory evidence is required across multiple domains:

NIST Control	Asset Inventory Connection
CM.L2-3.4.1: Baseline configurations	Intune device inventory confirms all in-scope devices are under management and have baselines applied
CM.L2-3.4.2: Security configuration enforcement	Intune compliance report demonstrates baseline enforcement; gap analysis (Entra vs. Intune) identifies unmanaged devices
SI.L2-3.14.1: Flaw remediation	Intune software inventory identifies devices with outdated OS or application versions
MP.L2-3.8.3: Sanitization	Device inventory identifies devices leaving scope (retired, reassigned) requiring sanitization
AC.L2-3.1.1: Authorized access	Intune enrollment report confirms only authorized, managed devices have access to CUI resources via Conditional Access with compliant device requirement
RA.L2-3.11.1: Risk assessments	Content Explorer label coverage report provides the data inventory input to risk assessment
CA.L2-3.12.4: System security plan	Asset inventory (devices, apps, data locations) is a required input to the SSP

Audit Evidence Package: Asset Inventory

Provide to CMMC assessors:

1. Intune device inventory CSV: all managed devices, enrollment date, compliance state, last check-in
2. Entra device list CSV: full tenant device list; compare to Intune for gap evidence
3. Content Explorer label coverage report: screenshot or export
4. Sanctioned/unsanctioned cloud app list from MDA Cloud Discovery
5. Entra enterprise application list: OAuth grants

Commercial

NIST SP 800-171 Rev. 3 Control Mapping

Control	Asset Inventory Connection
3.4.1: Baseline configurations	Intune device inventory with compliance state
3.4.2: Configuration enforcement	Gap analysis between Entra and Intune enrollment
3.14.1: Flaw identification	Intune discovered apps for software version tracking
3.1.1: Authorized access	Enrolled device list as the authorized device registry

SOC 2 Type II: CC6.1 (Logical Access)

The combination of Entra device inventory and Intune device inventory, supplemented by MDA cloud app discovery, satisfies the SOC 2 CC6.1 requirement to identify and manage the inventory of information assets. Provide the Intune device CSV, the Content Explorer label summary, and the MDA sanctioned app list to SOC 2 auditors.

---

Scoping Economics: Drawing the Boundary

The inventories above tell you what exists. Scoping decides which obligations each asset carries, and that decision has more cost leverage than any tool selection in this book. The common mistake is treating scope as one decision. It is two, because compliance controls sit on two different cost curves.

Two Cost Curves

	Hygiene tier	Boundary tier
Cost scales with	Endpoint and user count	Boundary size: every system, vendor, facility, and person in scope
Typical controls	MFA, patching, AV/EDR, least privilege, audit logging	Validated-encryption mandates, cloud and vendor assurance, incident-reporting blast radius, media/physical/personnel/maintenance process controls, legacy and specialized equipment
Right answer	Apply estate-wide, always; this is the device baseline, and it should not vary by data sensitivity	Contain deliberately behind a defined boundary

The hygiene tier is the large majority of every framework, and it is cheap at scale: a patched, protected, MFA-gated machine costs the same whether or not regulated data ever touches it. As of mid-2026 this tier carries the Pentagon's own endorsement: the DoW CIO's "Brilliant at the Basics" campaign, issued alongside the July 2026 CMMC Phase 2 suspension, distills it into voluntary Top 10 practice lists for IT and OT, guidance that applies whether one document is marked or ten thousand. The boundary tier is different. Each system, vendor, facility, and person added to scope adds documentation, assessment evidence, procurement constraints, and process obligations, whether or not a single additional file gets protected.

Boundary-tier control	GCC High (CMMC) name	Commercial name
Validated encryption	SC.L2-3.13.11 FIPS-validated cryptography	Encryption safe harbors in breach-notification laws
Cloud / vendor assurance	DFARS 252.204-7012(b) FedRAMP Moderate equivalency	SOC 2, due-diligence, and insurer questionnaires
Incident clock	DFARS 252.204-7012(c)-(g): 72-hour report, media preservation	Breach-notification timelines, hours to days
Documentation and assessment	CA.L2-3.12.4: SSP and evidence scale with component count	Auditor and insurer scope statements
Process families	3.7.x-3.10.x: maintenance, media, personnel, physical	The same processes, contract- and policy-driven
Exceptions	Specialized assets: in scope, limited assessment, SSP-documented	Legacy/OT exceptions, documented and segmented

GCC High (CMMC)

The boundary-tier controls that become prohibitive when applied estate-wide:

• SC.L2-3.13.11: FIPS-validated cryptography for every component protecting CUI. Estate-wide, this is a procurement veto across the SaaS portfolio, backup products, and appliances; inside a boundary, it is purchased once.
• DFARS 252.204-7012(b): FedRAMP Moderate (or equivalency) for every cloud service touching CUI. This single flow-down is the strongest economic argument for a contained GCC High boundary.
• DFARS 252.204-7012(c)-(g): the 72-hour reporting clock and media-preservation duties attach to every rated system; estate-wide, every helpdesk incident is a potential federal reporting decision.
• CA.L2-3.12.4: SSP depth and assessment evidence scale with in-scope component count, and assessment cost follows.
• 3.7.x / 3.8.x / 3.9.x / 3.10.x: maintenance, media sanitization, personnel screening, and physical protection attach to every in-scope facility, drive, and person.
• Specialized assets: per the CMMC scoping guide these are in scope with limited assessment, documented in the SSP and managed under risk-based policies. Segment them and control the CUI interface to them; do not claim a policy exclusion made them disappear.

Commercial

The same tier exists outside CMMC with different names:

• Encryption mandates and safe harbors: breach-notification laws commonly exempt properly encrypted data, which makes validated encryption on the regulated boundary the cheapest liability reducer available.
• Vendor assurance: every system that touches regulated data joins the SOC 2 / due-diligence / cyber-insurance questionnaire surface. A contained boundary means one short vendor list to defend.
• Breach-notification clocks: measured in hours to days once regulated data is plausibly involved. The smaller the set of systems where that data can live, the smaller the set of incidents that start the clock.
• Auditor and insurer scope statements: evidence effort scales with the number of in-scope components, exactly as assessment cost does in federal programs.
• Legacy and OT equipment: document the exceptions, segment them, and control the regulated-data interface to them, rather than pretending they are not there.

The Boundary Is a System Boundary the Label Makes True

A sensitivity label does three distinct jobs in this model, and keeping them distinct prevents both over-claiming and under-building:

1. The label enforces the boundary. DLP policies keyed to the label block regulated content from leaving designated locations (Data Loss Prevention Policies), and label encryption travels with the file (Sensitivity Labels), so content that leaks anyway arrives as ciphertext. Prevention plus failure containment.
2. The boundary scopes the process controls. Maintenance, media, personnel, and physical obligations attach to the systems and facilities in the documented scope, not to documents. The label cannot carry them; what it does is keep regulated data inside the boundary so that every other system remains honestly out of scope.
3. The evidence proves the negative. Content Explorer and Activity Explorer (earlier in this chapter) can demonstrate that zero labeled content exists on an out-of-boundary system. When an incident hits a system outside the boundary and the reporting-clock question arises, that report is the difference between "we believe no regulated data was involved" and "here is the record."

Deciding: Data Diffusion, Not Ambition

The variable that decides between a contained boundary and estate-wide application is how far regulated data is diffused through business processes. If it is confined to a few programs or departments, the boundary is the permanently correct architecture, not a starter posture. If every drawing, record, or transaction is regulated, high-water-mark estate-wide treatment is the honest answer, and running dual environments costs more than the uplift it avoids. Count the business processes that touch regulated data; the answer usually falls out.

The online edition of this section continues with the two encryption de-scoping debates (encrypted content at rest on out-of-boundary storage, and encrypted transit through conduits), which remain areas of assessor variance.

The De-Scoping Gray Areas (Extended)

Two arguments recur in boundary design, and neither is cleanly settled. Treat both as positions to document, not facts to assume.

Does encryption de-scope storage? The argument: a file encrypted by a sensitivity label, sitting on a system that has no access to the decryption keys, makes that system a courier carrying a locked box rather than a CUI asset. The counter-argument: scoping guidance defines assets by whether they process, store, or transmit CUI, without an explicit encryption carve-out for storage at rest, and assessors differ on whether key inaccessibility changes the category. If you rely on this position, document it explicitly in the SSP: the encryption mechanism, the key-access boundary, and the validation status of the crypto modules, and expect to defend it.

Does encryption de-scope transit? The stronger and more widely accepted variant: end-to-end encrypted regulated data transiting a network conduit does not pull the conduit into scope, because the conduit cannot access the content. Even here, document the position: which paths, which encryption, terminated where.

Both debates are exactly the class of high-impact gray area where assessment outcomes vary assessor to assessor, which is why they belong in a versioned pattern library with published positions rather than in tribal knowledge: state the position, the conditions under which it holds, the configuration that implements it, and the evidence artifact that proves it.