I run IT for a growing company of roughly 25–50 employees, and I'm currently the only person handling it. We moved from Google Workspace to Microsoft 365 during an acquisition and now rely heavily on Microsoft's ecosystem. Everyone has a Business Premium license, Windows devices are managed with Intune, Macs with Mosyle, Teams Phone uses Microsoft as the carrier, and many third-party applications use Entra ID for SSO. Windows users sign in with Windows Hello for Business, while Mac users rely on Platform SSO.
We currently back up Microsoft 365 data, including OneDrive content, to an on-premises Synology NAS using Active Backup for Microsoft 365. Our domains are already verified in Google Workspace, and users are provisioned there through SCIM, so I expect we could restore email there fairly quickly if necessary.
The areas I'm less confident about are Teams Phone numbers, device sign-in, Intune and Mosyle management, Entra/MSAL authentication for our internal employee hub, and access to other SaaS applications. I'm planning to work with a UK-based CSP and create a formal disaster recovery plan, but I'd like practical advice on improving resilience. In particular, what should we document or move outside Microsoft, and how can we ensure users can still work if the tenant becomes inaccessible?
5 Answers
Start by asking every prospective CSP exactly what their escalation and recovery process is if a customer tenant is locked, deauthenticated, or otherwise inaccessible. You want more than a promise to open a support ticket—ask who owns the incident, what emergency contacts exist, how admin access is recovered, and what responsibilities the CSP will actually take on. Keep that information in your recovery documentation.
Test the assumptions instead of relying on the backup product or cached logins to work. Confirm how long Windows Hello, cached Windows credentials, and Mac Platform SSO continue working without contacting the tenant, and determine what happens after a password reset, device replacement, token expiry, or new-user setup. Export or document Intune, Mosyle, DNS, SSO, application, and device configuration so replacement management can be established if required. Run a tabletop exercise covering email, files, phones, endpoints, identity, and communications, with clear owners and an order of operations.
Move the phone service, or at least the numbers, to an arrangement that isn’t completely dependent on the Microsoft tenant. If Microsoft-hosted calling becomes unavailable, you still need customers and staff to be able to reach the business. Operator Connect or an independent carrier may help, but confirm the exact number-porting, failover, and emergency-calling capabilities rather than assuming it removes every dependency.
Keep an offline recovery pack proving ownership of the company, domains, tenant, subscriptions, and phone numbers. Include registrar details, invoices, licensing records, tenant and domain IDs, support contracts, carrier information, backup locations, break-glass procedures, and current administrator contacts. Store it somewhere that does not require Microsoft authentication, and review it regularly.
Authentication is probably the hardest part to recover. Consider whether critical applications should have an independent identity provider or a second authentication route, especially the employee hub and systems needed during an M365 outage. Also make sure every important SaaS platform has a local admin account, recovery codes, tested alternate login method, and documented procedure that does not depend on Entra ID being available.
Moving authentication away from Entra only helps if the applications and recovery processes are designed to use that independent provider. If the main goal is recovering Microsoft 365 itself, an external identity provider won’t solve the tenant problem on its own; it mainly reduces the risk that every other business system fails at the same time.