Assess a Microsoft 365 tenant: technical inventory before operations or a handover

What must be checked before taking over or reorganizing a Microsoft 365 tenant? A reliable inventory includes more than users and licenses. It captures verified domains, identity sources, administrative roles, authentication, Conditional Access, enterprise applications, external access, Microsoft 365 groups, sharing settings, audit functions, and operational dependencies. The goal is not the longest possible report, but a reproducible as-is state with prioritized risks and clear actions.

A tenant can appear stable for years and still contain hidden dependencies: an undocumented app secret, a former employee as the sole owner of an automation, a partner with delegated rights, or a Conditional Access exception whose purpose no one knows. Before an operations takeover, such points must become visible so that changes do not unintentionally interrupt production processes.

Define the check goal and scope first

A tenant check can have different goals:

• Taking over ongoing operations,
• Security assessment,
• Preparing for a migration or consolidation,
• License and cost review,
• Introducing governance,
• Clarifying recurring disruptions,
• Preparing for an audit or certification.

The goal determines the depth. A complete technical takeover requires owners, dependencies, and fallback paths. A pure license review can be narrower. Still, every check should document what was checked, what was not checked, and what was evaluated only via sampling.

Start with read-only access

The inventory should initially use read roles. Global Reader covers many administrative views but does not replace every specialized role. For Service Health, Message Center, Enterprise Applications, and certain security and compliance areas, additional reader roles may be necessary.

These deviations belong in the check protocol. Write permissions are granted only when the analysis results in an approved implementation; this reduces the risk of changing production settings during data collection.

1. Tenant basic data and domains

At the start, the basic identifiers are documented:

• Tenant ID,
• primary and initial onmicrosoft.com domain,
• verified custom domains,
• purpose of each domain,
• DNS administrator and registrar,
• dependencies on Exchange, Teams, or third parties,
• existing test or legacy tenants,
• Data residency and organizational information, where relevant.

Problem: DNS responsibility is unknown

Microsoft 365 services can depend on DNS entries. If no one has access to the registrar or DNS zone, changes to mail flow, domain verification, or security configuration are blocked. The check should capture the entries and administrative responsibility.

Test

• Can an authorized internal person view the DNS zone?
• Are SPF, DKIM, and DMARC responsibilities clarified without changing values without review?
• Are domains no longer in use still connected to accounts, groups, or apps?

2. Identity source and user inventory

To check is how users are created and updated:

• exclusively cloud-based,
• synchronized from Active Directory or another source,
• automated from an HR system,
• manually by administrators,
• mixed model.

For each user category, status, owner, and lifecycle are considered:

• active employees,
• external guests,
• shared or functional accounts,
• administrative accounts,
• service accounts,
• deactivated users,
• former employees,
• test accounts.

Data fields that are often missing

Department, manager, employee ID, start and end dates, or account type are required for group-based assignments and lifecycle processes. Free text and inconsistent values complicate automation. Therefore, the check should evaluate existing objects and data quality.

Test

Select samples from each user class and verify:

1. Who is the business owner?
2. Where do the attributes originate?
3. Which groups and licenses are assigned?
4. Which authentication methods are registered?
5. What happens upon departure or when the purpose ceases?

3. Administrative roles and privileged access

All active and, when using PIM, authorized role assignments are recorded. Particularly relevant are:

• Global Administrator,
• Privileged Role Administrator,
• Conditional Access Administrator,
• Authentication Administrator and Privileged Authentication Administrator,
• Exchange, SharePoint, and Teams Administrator,
• Application Administrator and Cloud Application Administrator,
• Security and compliance roles,
• Group and user administration.

The assessment clarifies primarily:

• Why is it needed?
• Is it permanently active or only on demand?
• Is the account a separate administrator account?
• Is strong authentication configured?
• Is there a backup?
• When was the need last confirmed?

Error scenario: unknown global administrator

The account may belong to a previous service provider, former employee, or test project. Before revoking access, verify whether automations, app objects, or recovery processes depend on it. Then, remove access in a controlled manner and verify the result in sign-in and audit logs.

4. Authentication methods, MFA, and SSPR

The check does not only capture whether MFA is "active." The following are relevant:

• which methods are allowed,
• which groups they apply to,
• whether Conditional Access or other mechanisms enforce MFA,
• whether Self-Service Password Reset is configured,
• how new users register their first strong method,
• how the helpdesk proceeds in case of device loss,
• whether Temporary Access Pass is used in a controlled manner,
• whether privileged accounts use phishing-resistant methods.

Error scenario: user cannot sign in after smartphone change

A secure recovery process requires identity verification, authorized helpdesk roles, and a documented method, such as resetting existing registrations or issuing a time-limited Temporary Access Pass. Improvising by removing all security requirements is not an appropriate fallback path.

5. Conditional Access

All policies are exported or documented with the following characteristics:

• Name and business purpose,
• Status: off, report-only, or active,
• Target users and groups,
• Excluded identities,
• Target resources,
• Conditions such as location, platform, or client app,
• Grant and session controls,
• Dependency on device management or authentication strength,
• Owner and last review date.

Multiple applicable policies are evaluated together. Therefore, individual assessment is insufficient. The What-If test and real login logs help understand the combined effect.

Critical test

• Do Emergency Access accounts work?
• Are old authentication protocols handled appropriately?
• Are service accounts or devices with special requirements documented clearly?
• Are there broad exclusion groups that undermine policy effectiveness?

6. Enterprise Applications and App Registrations

The tenant check captures:

• all relevant service principals under Enterprise Applications,
• own app registrations,
• delegated and application permissions,
• admin consent,
• user and group assignments,
• single sign-on configuration,
• app owners,
• certificates, secrets, and expiration dates,
• last login or usage indicators,
• publisher and manufacturer information.

Error scenario: app without owner

A technically functional application can be business-critical even though no one holds responsibility. Before making changes, determine through login logs, target systems, source code repositories, automations, and business teams what it is used for.

The difference between app registration and service principal is explored in detail in the post Distinguish Enterprise Applications and App Registrations.

7. Groups, Teams, and SharePoint structures

Microsoft 365 groups often connect Teams, SharePoint, Exchange, and other services. Therefore, the count includes more than just visible teams. The following must be checked:

• Group and team owners,
• Groups without owners,
• Private and shared channels,
• External members,
• Archived or inactive teams,
• SharePoint sites without a clear purpose,
• Sharing settings at the tenant and site level,
• Anonymous or "Anyone" links, if permitted,
• Sensitivity and lifecycle concepts,
• Storage and deletion dependencies.

Test

Select a typical project group and trace the entire access path: Identity → Group membership → Team → SharePoint site → Library or file. This reveals whether permissions arise through groups, direct sharing, or links.

8. Licenses and assignment logic

The license check distinguishes:

• Acquired products,
• Assigned licenses,
• Group-based and direct assignments,
• Deactivated service plans,
• Assignment errors,
• Unused or duplicate assignments,
• Features that depend on Premium or Governance licenses.

An unused license is not automatically dispensable. An account may be needed for retention, mailbox access, or transition processes. Before revocation, technical and legal consequences must be checked.

9. Logging, audit, and monitoring

Items to check:

• Access to Entra sign-in and audit logs,
• Retention period and export requirements,
• Diagnostic Settings or SIEM integration, if available,
• Service Health and Message Center,
• Alerts for privileged events,
• Monitoring of app credentials,
• Documented incident and escalation paths.

Microsoft Entra audit logs capture changes to users, groups, applications, and licenses. Sign-in logs show interactive and other sign-in types. How long data is available depends on the service and license and must be verified at the time of the check.

10. Prioritize results

An audit report should organize findings by risk and feasibility. A possible schema:

Priority: P0

Significance: acute access protection

Example: no functioning emergency access

Priority: P1

Significance: high risk of misuse or outage

Example: unknown global admin, app secret expiring soon

Priority: P2

Significance: relevant governance gap

Example: guests without sponsor or review

Priority: P3

Significance: optimization

Example: inconsistent naming convention

Each finding includes evidence, impact, recommended action, dependencies, responsible role, and rollback path.

Fallback path for faulty cleanups

An inventory assessment often creates the desire to clean up immediately. It is precisely here that outages occur. Before deleting or revoking, distinguish between:

• disable or block as a reversible preliminary step,
• remove assignment instead of deleting the object immediately,
• rotate credentials in parallel instead of removing the old ones immediately,
• Report-only or pilot group instead of tenant-wide activation,
• add owners before removing the former account.

The fallback plan documents the previous state and the maximum time within which restoration is meaningfully possible.

Acceptance tests after the inventory assessment

The check is complete when data has been collected and critical assumptions have been tested:

1. Internal administrators can reach the tenant independently.
2. Emergency access works and triggers monitoring.
3. For critical apps, owners and expiration dates exist.
4. A typical user setup and an exit are traceable.
5. External access can be traced from identity to resource.
6. Changes are found in audit logs.
7. License assignment errors have been identified.
8. Service notifications reach the responsible persons.
9. Critical measures are prioritized and not just listed.
10. The as-is state is documented so that a second person can reproduce it.

For follow-up steps from the inventory assessment, three deep dives are particularly helpful: The operating model for Microsoft-365 administration assigns responsibilities and ongoing administration, securely implementing Conditional Access deepens access rules, and the Microsoft-365 emergency account secures the fallback path.

How the tenant check becomes a robust administration plan

A good tenant check combines technical inventory with ownership, risk, and operational capability. It shows which objects exist, why they are needed, who is responsible for them, how they are monitored, and how changes can be safely rolled back. Only this linkage makes the inventory assessment a foundation for safe self-operation or a controlled operational takeover.