Last reviewed: October 2026
No Credit Card Required
Printed from checkflow.io/templates/managed-services/microsoft-365-tenant-onboarding-checklist
When an MSP takes on a client’s Microsoft 365 tenant, the first job is not hardening it. It is finding out who can already get in. Inherited tenants often carry an old provider’s partner access, Global Administrators nobody can name, an app with permission to read every mailbox, and an inbox rule copying the finance mailbox to a personal address. This free Microsoft 365 tenant onboarding checklist takes one tenant from first access to a documented starting point. It sets up GDAP with least-privileged roles, creates two emergency access accounts, cuts back standing admin rights, enforces MFA, switches on audit logging and closes the usual Exchange Online, SharePoint and Teams gaps. A conditional phase removes what a previous provider left behind, and nothing is enforced until the service manager approves the Conditional Access rollout plan.
This checklist runs once per tenant, at the start of an agreement or when a client adds Microsoft 365 to one. Its output is a tenant you can account for: your access arranged through GDAP, the old access gone, MFA enforced, logging on and a list of every setting you decided not to apply. That list is what the Microsoft 365 Security Baseline Review Checklist compares against each quarter afterwards. Without it, the first review mixes what you inherited with what changed on your watch.
Two neighbouring checklists cover the rest of a takeover. The MSP Client Onboarding Checklist is the whole-client project, and it treats the tenant as one line in its credentials phase. This page is the detail behind that line. DNS records for the client’s domains belong to the Email Authentication Setup Checklist. This checklist starts that project for each domain rather than repeating it.
Starts from: whatever the client or the last provider left.
Main work: access, clean-up and first enforcement of MFA.
Decisions: security defaults or Conditional Access, sharing levels, exceptions.
Leaves behind: a documented starting point and a Secure Score baseline.
Starts from: the onboarding record and the last review.
Main work: spotting settings that moved and admins who appeared.
Decisions: fix, raise a ticket or renew an exception.
Leaves behind: a signed review and an updated exception register.
From the GDAP request to a documented handover, in seven phases. Phase 2 appears only when another provider managed the tenant before you.
The scope answer in task 2 decides whether the previous-provider phase appears. Complete it before anyone signs in to change things.
Shown only when another provider managed the tenant. Confirm which partners the client still uses before removing anything.
Microsoft publishes guidance on the least-privileged Microsoft Entra role for each task a partner performs. Build GDAP security groups around the jobs your technicians do, and request a time-bound Global Administrator relationship only for the rare task nothing narrower can perform. The grouping shown is common practice, not a Microsoft rule.
| Job | Least-privileged role | Typical group |
|---|---|---|
| Reset a user’s password | Password Administrator or Helpdesk Administrator | Service desk tier 1 |
| Reset MFA methods for a non-admin user | Authentication Administrator | Service desk tier 1 |
| Create, update or block users and groups | User Administrator | Service desk tier 1 |
| Assign or remove licences | License Administrator | Service desk tier 1 |
| Raise a Microsoft support request | Service Support Administrator | All tiers |
| Manage shared mailboxes and mail flow rules | Exchange Administrator | Tier 2 or messaging |
| Enrol and troubleshoot devices | Intune Administrator | Tier 2 or endpoint |
| Read configuration without changing it | Global Reader or Security Reader | Reviewers and vCIOs |
These details change. Check them against Microsoft’s documentation at the start of each onboarding.
Every tenant goes through the same phases in the same order, so nobody enforces Conditional Access before the break-glass accounts exist. Conditional logic adds the previous-provider phase only for tenants that need it.
The rollout plan is an approval task assigned to the service manager. Nothing after it can be completed until the answer is Approved, and the client’s written agreement sits on the same task as the decision.
Admin accounts, apps and forwarding rules found in the first week are recorded with screenshots against the task that found them, so when a client later asks who created an account, the record answers.
The MSP process management guide counts security baseline configuration and access provisioning among the onboarding steps that suffer when each technician does them differently. See how CheckFlow for MSPs runs projects like this for every client from one place.
If MFA registration in Phase 4 shows a long tail of unregistered users, hand them to the MFA Rollout Checklist, which handles communication and registration. Once the tenant is handed over, the Privileged Access Review Checklist keeps the admin roles you cut back from growing again.
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
It is the one-off work of taking responsibility for a client’s tenant. You set up delegated access through GDAP, remove access left by anyone before you, create emergency access accounts, reduce standing admin rights, enforce MFA and switch on audit logging. Then you set the main Exchange Online, SharePoint and Teams controls, record a Secure Score baseline and document every exception, giving your recurring reviews a starting point.
Microsoft allows anything from 1 to 730 days. A common approach is to request the maximum for day-to-day roles and enable auto-extend, which adds six months at a time, so access doesn’t lapse in the middle of an agreement. Keep any Global Administrator relationship separate and short, because it can’t auto-extend and should be the exception. Record the end date in the PSA either way.
It depends on the licence. Security defaults are free, require MFA registration for everyone and block legacy authentication, but they can’t be customised. Conditional Access needs Entra ID P1, which Microsoft 365 Business Premium includes, and lets you exclude break-glass accounts, require stronger methods for admins and add device rules. You can’t run both, so build the policies in report-only mode first and switch security defaults off only when they are ready.
No. Microsoft’s enforcement covers sign-ins to its admin portals and Azure management tools, not users opening Outlook, Teams or SharePoint. Staff can still be reading mail with only a password, so enforce MFA for every user with security defaults or Conditional Access. Make sure emergency access accounts use a passkey or certificate, as they are not exempt.
The client should be able to use them without you. Microsoft’s guidance is that emergency access accounts aren’t tied to one person and their credentials are kept in separate secure locations available to the people authorised to use them. For a managed client, a common arrangement is one passkey held by the client’s nominated contact and one held by the MSP, with sign-in alerts going to both. Agree it in writing.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
