Multi-factor authentication protects the people signing in. It does nothing about the applications you have already told Microsoft 365 to trust. Each of those has an application identity of its own, holds permissions you consented to once, connects with its own credentials, and never sees a login prompt.
Most organisations cannot say how many of them there are. A migration tool consented to three years ago, a backup service, a reporting add-in somebody trialled: each one keeps the access it was granted until a person removes it. Nobody gets an expiry reminder.
October 2026 showed what that looks like when it goes wrong. This guide explains why MFA has nothing to do with it, how to see what your tenant already trusts, and what to do about the entries you no longer recognise.
An attacker holding a vendor’s application credential does not need your password, your token or your phone. They inherit the permissions you granted the vendor, and no amount of multi-factor authentication on your users changes that.
Why MFA Does Not Apply to an Application Identity
Two different things sign in to Microsoft 365, and they authenticate in different ways.
A person signs in interactively. They present a password, then a second factor, and Conditional Access evaluates the device, the location and the risk before letting them through. That is the path MFA sits on.
An application signs in as itself. Its application identity in your directory is what Microsoft calls a service principal, the local identity an app gets when you consent to it, and Microsoft documents the distinction between the app and that principal. It authenticates with a secret or a certificate, receives an app-only token, and acts with the permissions you granted. There is no user, so there is no second factor to present and no interactive session to challenge.
This is not a flaw. Automated services have to work at 2am without a human to approve them. But it means two of the controls most organisations rely on do not apply:
- MFA is irrelevant. No user, no prompt.
- Conditional Access policies scoped to users do not fire. Many estates have no policy covering workload identities at all.
- Revoking user sessions does nothing. It ends people’s sessions, not an application’s tokens.
How an Application Identity Attack Works
The sequence is short, which is part of the problem.
- A vendor builds a multi-tenant app and holds one set of credentials for it.
- You consent to that app, which creates a service principal in your tenant carrying the permissions you approved.
- Someone obtains the vendor’s credential.
- They authenticate as the application and request tokens in any tenant where it is installed.
- They act with your consented permissions, from their own infrastructure.
Step four is the uncomfortable one. A multi-tenant application identity credential is not scoped to one customer, so a single compromise reaches every tenant that ever said yes. Your own security posture does not change the outcome, because nothing about the attack touches your users, your devices or your network.
Worse, the permissions are often broader than the job required. Mail.Read across the whole tenant is easier to grant than per-mailbox scoping, so that is frequently what was approved.
Do you know what your Microsoft 365 tenant already trusts?
Our team will go through the applications consented in your tenant, what permissions each one holds, and which can be removed, then show you what ongoing monitoring of application activity would cover.
Book a tenant reviewWhat This Looked Like in October 2026
A worked example, because the shape of it is more instructive than the vendor’s name.
In mid-October 2026 a credential belonging to ConnectWise Cloud Backup, a widely used Microsoft 365 backup product formerly sold as SkyKick Cloud Backup, was compromised. The attacker authenticated with that application identity and requested app-only Graph tokens in customer tenants. No user signed in anywhere, and no customer received an MFA prompt.
| Date | What happened |
|---|---|
| 13 to 14 October | Scripted sign-in attempts observed from the attacker’s infrastructure, per Huntress |
| 15 October | Microsoft Threat Intelligence reported broad successful sign-ins from a malicious IP address |
| 17 October | ConnectWise began mitigations, disabling seven application identities and revoking their certificates |
| 18 October | Two further services taken offline as a precaution |
On scale, be careful with the numbers, because they measure different things. Huntress confirmed unauthorised sign-ins in at least 162 tenants and said compromises beyond its own telemetry were likely. It separately saw sign-in activity from the attacker’s address across almost 1,000 tenants, more than 300 of which appeared to succeed, while noting it had not confirmed the same operator was behind both. Help Net Security has the detail.
Two findings matter more than the totals. In around 50 organisations, vendor applications assigned themselves directory roles, most often Exchange Administrator. And new client secrets were planted on applications with expiry dates years out, which is persistence that survives the original credential being revoked.
ConnectWise said it had no indicators that partner backup data was accessed, that archives remained encrypted and isolated, and that it had engaged outside forensics. It also said it cannot see inside customer tenants, so it could not tell any individual customer whether they were affected. That last point is the one to sit with.
How to See What Third-Party App Access Your Tenant Already Grants
Start with the inventory, not the incident. In the Microsoft Entra admin centre, open Enterprise applications and read it as a list of standing permissions rather than a list of software.
For each entry, establish four things:
- What it is for, and whether that is still true
- What permissions it holds, particularly tenant-wide application permissions rather than delegated ones
- Who owns it internally, by name
- When it was last used
Microsoft’s guidance on reviewing and revoking application permissions covers the mechanics. The judgement is yours: an app with Mail.ReadWrite across every mailbox is a different risk from one reading a single calendar, even though both appear as one row.
Expect the list to be longer than you think, and expect several entries nobody present can explain. That is the normal finding, not a sign of negligence.
What to Look For in the Sign-In Logs
There is a trap here that catches experienced administrators. Application identity activity is not where you would look first. The sign-in log you open by default shows user sign-ins. Application activity sits on a separate tab, and Microsoft’s sign-in logs documentation sets out the different types. Searching the wrong view produces a clean result and false comfort.
Go to the service principal sign-ins view and work through:
| Check | What you are looking for |
|---|---|
| Service principal sign-ins | Source addresses that do not belong to the vendor, and sign-ins outside normal service patterns |
| Credentials added to applications | Any secret or certificate you did not add, especially with long expiry dates |
| Directory role assignments | Applications holding admin roles, and anything that assigned itself one |
| Consent grants | New grants, and permission scopes that grew without a change request |
| Application owners | Owners added that you cannot account for |
| Mail rules and transport rules | Forwarding created through an API rather than by a person |
Two honest caveats. Matching an address or a user agent is a lead, not proof of compromise. And some directory reads through Graph leave limited audit evidence, so a clean search narrows the question without closing it. If you find persistence, treat it as an incident and get help; our managed SOC guide covers what that response looks like.
How to Contain an App You No Longer Trust
Four things, in order, and one of them is counter-intuitive.
- Disable the service principal, do not delete it. Deleting destroys the configuration and the evidence, and you may need both.
- Understand what disabling does not do. It stops new tokens being issued. Tokens already issued stay valid until they expire.
- Remove credentials you did not add, because revoking the vendor’s credential does nothing about a secret the attacker planted on a different app.
- Undo the changes made while access was live. Vendor-side containment does not reverse a role assignment or a mail rule inside your tenant.
That third point is where most tenant reviews stop too early. One application identity gets revoked and another keeps working. The original credential gets revoked, the headline incident closes, and a secret planted on a second application quietly keeps working. Audit every application for credentials added during the window, not just the one that was named.
Why Dormant Consent Is the Bigger Problem
Live integrations get noticed when they break. Dormant ones do not, and they keep their permissions indefinitely.
Microsoft 365 migrations are the clearest case. A tool is consented to with broad mailbox permissions, the migration finishes, the project closes, and the consent stays. Years later nobody remembers granting it, the vendor may have been acquired and the product renamed, and the entry no longer matches the name anyone would search for.
Three habits help:
- Search by application ID, not display name. Products get renamed and rebranded. The identifier does not change.
- Make removal part of project closedown. If a tool was consented to for a migration or a one-off report, revoking it belongs on the completion checklist.
- Review consent on a schedule. Quarterly is enough for most estates, and it is the only way dormant entries ever surface.
If you are planning a migration now, decide the revocation step before you grant anything. Our guide to tenant to tenant migration covers the wider sequence.
What to Ask Any Vendor With Tenant Access
This is a supply chain question, and the NCSC’s supply chain security guidance is the right frame. Five questions worth putting in writing:
- Is the application multi-tenant, and is the credential shared across your customers?
- How are those credentials stored and rotated, and how often?
- What is the minimum permission set the product needs, as opposed to what it requests?
- How quickly would we be told, and through which channel, if your credential were exposed?
- Can you see into our tenant to tell us whether we were affected, or would that be our job?
The last one is the one that catches people out. A vendor can honestly say it has found no evidence of compromise and still have no way of knowing what happened in your environment. Those are two different statements, and only one of them is about you.
Apply the same questions to us. Any provider with access to your tenant, including Transputec, should be able to answer all five without preparation.
Conclusion
Identity has moved from people to workloads, and most monitoring has not followed. An application identity is still an identity. The controls that stop a stolen password do nothing about a stolen application credential, and the permissions involved were granted deliberately, by someone who no longer works on that project.
None of this requires a new product. It requires an inventory of what your tenant trusts, monitoring that includes application sign-ins, and a habit of removing consent when the work that needed it ends.
If you want help getting through the first pass, talk to our team about the security work behind Transputec’s managed SOC services, which includes monitoring identity and application activity across your estate. Our explainer on SaaS security posture management covers how this is governed continuously rather than once a quarter.
Frequently Asked Questions
Does MFA protect against application identity attacks?
No. Multi-factor authentication applies when a person signs in. An application authenticates as itself using a secret or certificate and receives a token without any interactive login, so there is no prompt to satisfy. Conditional Access policies scoped to users do not evaluate that traffic either. Protecting application identities needs different controls: least-privilege consent, credential hygiene at the vendor, and monitoring of each service principal sign-in.
How do I check which third-party apps have access to Microsoft 365?
In the Microsoft Entra admin centre, open Enterprise applications for the full list of what your tenant has consented to, then review each entry’s permissions, owner and last use. Check the service principal sign-ins view rather than the default user sign-in log, because application traffic is recorded separately. Search by application ID rather than display name, since products get renamed and rebranded after acquisitions.
How do I review Global Administrator and other admin roles in Entra ID?
Open Roles and administrators and review the membership of every privileged role, Global Administrator first. Check for applications and service principals holding directory roles, not just people, because an application can be assigned one. Then look at the audit log for role assignment events and confirm each has a change request behind it. In the October 2026 incident, roughly 50 organisations had vendor applications assign themselves roles, most often Exchange Administrator.
What should we do if we used SkyKick for a Microsoft 365 email migration?
Check whether the consent is still in your tenant, which it often is, because migration tools are rarely revoked at project closedown. Search Enterprise applications by application ID rather than by name, since SkyKick Cloud Backup was rebranded as ConnectWise Cloud Backup. If you find it, disable rather than delete it, review service principal sign-ins and credential additions over the exposure window, and check for role assignments or mail rules you did not create. Follow the vendor’s own advisory for the current application identifiers.
Is removing an app's consent enough to stop the access?
Not on its own. Disabling a service principal stops new tokens being issued, but tokens already issued remain valid until they expire, and revoking user sessions does not affect application access at all. You also have to remove any credentials added to other applications during the exposure window and reverse changes made while access was live, such as role assignments or forwarding rules. Vendor-side revocation does not reach inside your tenant.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
