In our tenant all the admins were blocked from logging into their accounts.

Dear PRAGATI EM SCHOOL RAJAHMUNDRY,

Based on the screenshot, the error message "This username may be incorrect. Make sure you typed it correctly. Otherwise, contact your admin." typically indicates that Microsoft Entra ID (Azure AD) cannot locate the account in the tenant, or there may be an issue affecting administrator accounts specifically.

Since all administrator accounts are affected while standard users can still sign in, this is not a normal password or MFA issue and may require investigation by Microsoft's Data Protection or Account Recovery team.

As you currently do not have access to any administrator account, unfortunately no one in the tenant can open a support ticket through the Microsoft 365 Admin Center. In this situation, the recommended option is to contact Microsoft Support through an alternative channel and explain that all admin accounts in the tenant are inaccessible. Be prepared to provide proof of ownership and tenant information, as Microsoft may need to validate ownership before assisting.

You might need to contact Microsoft Support team via phone service number: Customer service phone numbers - Microsoft Support

If you can't create a support ticket during the call, I recommend creating a temporary tenant account and submitting the support request from there. To create a new tenant, follow these steps:

1. Visit Office 365 E3 - Enterprise Collaboration and Productivity | Microsoft    
2. Select any plan and click Try for free.    
3. Complete the setup to create a new tenant.    
4. Ticket support: In the Microsoft 365 admin center>support>help & support. You can create a support ticket: https://admin.microsoft.com/#/support/requests     

Important: Please remember to cancel the trial subscription once your issue is resolved to avoid any charges.

Because this issue affects all admin accounts simultaneously, only Microsoft Support may be able to determine whether the administrator objects were modified, deleted, or impacted by a tenant-level configuration issue.

I hope information above can help you resolve the issue, feel free to reach out if you have any other questions.

If the answer is helpful, please click "Yes". If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

Unless you work in a complex authentication environment where your admin sit in some sort of special group that can no longer be accessed via Azure AD (out of my knowledge depth), for common M365 tenants, I would assume an act of sabotage or admin take over, and all admins are now removed by the attacker and replaced with their own. Misconfigured access policies do not result in not able to find the admin user account, just unable to login. The most highly suspect is sabotage or account takeover. The next step in the attack playbook is to download your data, attempt BEC, or find other information to exploit, eg emailing your customers or suppliers with compromise emails using real email domain etc. In such a case, using the 8D template for problem solving, this is what I might do. You can use your own incident playbook if you have one -

8D – Tenant incident (assume compromise)

D2 – Problem

Admin sign-in: “This username may be incorrect”

Normal users can still sign in

Working assumption: admin accounts deleted after compromise; treat as possible BEC

D3 – Contain now (I used AI to generate this, check details for accuracy)

Call Microsoft Data Protection / Tenant Recovery. Restore a known Global Admin only.

Lock domain registrar, DNS, billing, and partner/CSP portal.

Warn all staff out of band (WhatsApp, SMS, phone, in person). Do not rely on email.

Confirm every person received the message. Chase anyone who does not reply.

Warn customers, banks, vendors, and payroll out of band: ignore payment-change or urgent-wire requests from us until verified by phone.

Confirm those third parties received the warning.

Staff must not approve MFA prompts, app consents, or new mail forwarding.

Stop extra admin login attempts from random devices.

When one admin is restored: clean PC → reset password → wipe MFA → revoke sessions → disable unknown admins.

D4 – Root cause

After access is back, check audit logs for deleted users, new Global Admins, and new app consents.

D5 – Correct

Remove attacker admins, apps, guests, unknown users, forwarding, and inbox rules.

Restore legitimate admins from Deleted users if present.

D6 – Verify

Only known admins remain.

Sign-in and audit logs look normal.

D7 – Prevent

Two break-glass admin accounts (will not prevent take-over, but can help in other lockouts).

Physical token based MFA for all admins.

D8 – Close

Short incident write-up.

Quickest way is either to call (if possible) or via demo account admin - tell them exactly what you suspect. Your registered global admin for the locked account need to create the demo account and raise the ticket.

Good luck

Also, if you purchased your licenses from a reseller (Microsoft CSP reseller), they (or their distributor) might also have elevated escalation path in account takeover scenarios.

For example I have heard instances where a reseller purchasing from distributor Pax8, Pax8 may on case by case, utilize a Microsoft premium support incident to escalate resolution, if not, at least potentially help you escalate via back channel. Potentially worth exploring if you are entitled to this option.