The new SaaS attack path: when a legitimate login grants the wrong app access

What changed

The attack is not always about stealing a password. Microsoft observed three routes: voice phishing that persuaded users to approve an attacker-controlled OAuth application, compromise through trusted integrations and workflows, and misconfigured guest access.

Once approved, a connected application can inherit the user’s legitimate permissions and make authorised-looking API calls. That can enable CRM discovery, persistent access and data extraction while producing fewer of the authentication signals that many teams expect from a conventional account takeover.

Microsoft explicitly states that the activity was not caused by an inherent Salesforce vulnerability. The weakness was the surrounding trust model: who can approve applications, which integrations remain connected, what guests can reach and whether application-level activity is being monitored.

Why MFA is necessary—but not sufficient

Strong, phishing-resistant MFA remains essential. Microsoft separately announced that Entra ID will begin making passkeys the default authentication experience from 1 September 2026, and the NCSC recommends stronger MFA for corporate services.

But a passkey protects the sign-in event; it does not automatically make every consent decision, third-party integration or guest configuration safe. If a logged-in employee is socially engineered into approving a malicious application, the resulting token may provide access without the attacker repeatedly signing in as that employee.

For an SMB, identity security therefore needs two layers: protect the human login and govern the applications that are allowed to act on behalf of people.

A practical control plan for SMBs

Start with visibility. Build an inventory of connected applications across Microsoft 365, Google Workspace, CRM, accounting, support and marketing platforms. Record the owner, business purpose, permissions, data reached and last use of each integration.

Then reduce standing trust. Restrict user consent where the platform allows it, require review for high-impact permissions, remove dormant integrations, review guest accounts and separate administrator identities from daily work.

Finally, make the controls operational. Retain identity and application logs, alert on new high-privilege connections, define a token-revocation procedure, test data exports and backups, and ensure someone is responsible for reviewing access changes—not only installing security products.

Where brianda.cloud fits

brianda.cloud can map SaaS identities and integrations, review permissions and guest access, strengthen MFA and passkey rollout, connect useful alerts, and align those controls with managed firewall, backup and recovery operations.

The result is a smaller trust surface and a clear response path if an application, token or external integration becomes suspicious. The first step is a focused access review rather than a disruptive platform migration.