Entra ID is your new perimeter: what the latest app-credential attacks tell us

No password, no MFA prompt, still signed in 

On 1 November 2026, an attacker began signing in to Microsoft 365 and Azure tenants as trusted applications, using stolen app credentials that were still valid. Within three days they had reached at least 27 organisations, according to security researchers who are still investigating. 

No Microsoft vulnerability was involved. No user was phished. The attacker simply held the keys that applications use to sign themselves in, and Entra ID let them in. 

The main targets were managed service providers, because one MSP app can open the door to every client it manages. In one case, a single multi-tenant app was used to sweep 15 client tenants in roughly 10-second loops. Victims span government, legal, education, energy, construction and nonprofits. 

This is the clearest sign yet of a shift many security teams have been warning about: Entra ID is no longer just your login page. It is your perimeter. 

Why app identities slip past your defences 

Most organisations have spent years hardening user sign-ins: MFA, Conditional Access, phishing training. Applications sign in differently. A backup tool, an automation script or an MSP management app uses a client secret or certificate to authenticate as a service principal, with no human involved. 

That creates three blind spots: 

1. No MFA. An app sign-in never triggers an MFA prompt. A valid secret is all it takes. 
2. User-focused policies don’t apply. Conditional Access policies scoped to users don’t cover service principals. Workload identity policies exist but need extra licensing and don’t cover multi-tenant or third-party apps. 
3. Broad, long-lived permissions. Apps are often granted wide Microsoft Graph, SharePoint or Key Vault access when they’re set up, then forgotten. Secrets can sit valid for months or years. 

In this campaign, the attacker used each app’s access to request tokens for Azure Resource Manager and Key Vault, harvesting more secrets within minutes. It then searched SharePoint and downloaded files about credentials and configuration: password lists, VPN profiles, firewall configs and backup-storage credentials. 

Part of a wider pattern 

This isn’t a one-off. Through 2026, attackers have increasingly gone after Entra ID itself rather than individual mailboxes or devices: 

• Abused third-party apps. In October 2026, a state-aligned group abused a cloud backup vendor’s multi-tenant Microsoft 365 app to sign in to customer tenants. Researchers assess it as unrelated to the November campaign, but the technique is similar. 
• Spoofed app IDs. In July 2026, researchers documented attackers using fake OAuth client IDs to test stolen passwords in Entra ID without leaving a normal successful sign-in record. 
• Secrets as the prize. Attackers increasingly target Key Vault and other secret stores, because one stolen secret can unlock many more systems. 

The common thread: every app you connect to Microsoft 365 is an identity, with its own keys and permissions. Many organisations have dozens they’ve never reviewed. 

What to check this week 

1. Search your sign-in logs. In the Entra admin centre, go to Sign-in logs and check both Service principal sign-ins and Non-interactive sign-ins for 199.19.77.84 (high confidence). Also check 199.19.77.18 and 65.87.223.26 (lower confidence). Look back as far as your retention allows. 
2. Treat failures as a warning. Error codes AADSTS7000215 (invalid secret) and AADSTS7000222 (expired secret) from unfamiliar addresses mean someone may hold one of your app credentials. 
3. Block the confirmed address. Add 199.19.77.84/32 as a named location and block it in Conditional Access. Block the single IP, not the whole hosting range. 
4. Inventory your apps. List every app registration and enterprise app, who owns it, what it can access and when its secrets expire. Remove what you no longer use. 
5. Cut back permissions. Apply least privilege, especially for apps with Graph, SharePoint or Key Vault access. 
6. Move away from client secrets. Where possible, use managed identities, workload identity federation or certificates, and cap secret lifetimes. 
7. Keep secrets out of documents. Don’t store credentials in SharePoint, wikis, tickets or scripts. That’s exactly what this attacker searched for. 

If you find a match, remove the app’s credentials, revoke sessions, rotate anything the app could reach, and involve your security and legal teams early. 

Plan for the day prevention fails 

Good hygiene reduces the risk, but once an attacker is inside Entra ID, they can change, delete or encrypt whatever those identities can reach. The question to ask is: if that happened tomorrow, how quickly could you get back to where you were the day before? 

Many organisations back up their Microsoft 365 data but not Entra ID itself. That leaves a gap: 

• Your data is only half of it. Entra ID controls who can access what. Without a backup, recovering means rebuilding users, groups, roles, Conditional Access policies and app settings by hand, which can take weeks for a larger organisation. 
• Restore to before the attack. An Entra ID backup lets you roll identities and configuration back to a known-good point in time, and in some cases restore into a clean, separate tenant. 
• Keep backups independent. A backup that sits outside Microsoft 365, with its own access and immutable storage, stays out of reach when your tenant is compromised. 

If you’re backing up Microsoft 365 but not Entra ID, now is a good time to close that gap. BackupVault has spent more than 20 years helping organisations recover when things go wrong, and our UK-based team can help you choose the right Entra ID backup for your setup, with a free 30-day trial.