How we protect the Microsoft 365 access you grant SuperIT

Attackers have shifted from MSP user accounts to the vendor apps those MSPs trust.

The recent incidents follow one pattern, which Microsoft Threat Intelligence has documented. Someone steals a credential belonging to a vendor’s multi-tenant Entra app registration, then signs in as that app’s service principal in every tenant that consented to it. There is no user sign-in, so MFA doesn’t apply. Conditional Access for workload identities doesn’t help either, because Microsoft limits it to single-tenant apps registered in your own tenant, and a vendor’s app is multi-tenant. In the worst cases the app then grants itself a directory role, or plants new secrets on other trusted apps.

Since then, MSPs have been sending us detailed questions about how SuperIT’s Microsoft integration is built. This post publishes the substance of our answers.

• SuperIT doesn’t use GDAP or Partner Center. Each client tenant consents to our application directly, and the app holds no directory roles.
• Our app registrations use client secrets today. We rotate them at least every 30 days, keep them in a managed secret store and encrypt tokens at the field level, and we’re assessing workload identity federation to remove the stored secret.
• App instance property lock is on for our production apps, and you can get our app IDs and outbound IPs to monitor us in your own tenants.
• We found no evidence that SuperIT was affected by or targeted in the recent incidents. If that changes, you hear from us within 24 hours.

We have also included a five-step review worth running against every vendor app in your client tenants.

How SuperIT connects to your tenants

We don’t reach your clients through GDAP or Partner Center. Each tenant connects to our Microsoft application directly, one at a time.

• An administrator in each tenant grants consent to the SuperIT application during setup. The permissions granted then define everything the app can do in that tenant.
• You choose which tenants to connect. Connecting one client tenant does nothing to the others, and there’s no “connect all” through a partner relationship.
• We never obtain or store Partner Center or GDAP tokens. An attacker who reached our systems would find nothing that lets them pivot through your partner relationships, which is the path the Key Eater campaign tried to use.
• Granting consent needs an administrator. The SuperIT application itself holds no directory role in your tenant.
• The integration requests short-lived access tokens from Microsoft when it needs them, and their lifetime follows Microsoft’s rules. Where a workflow needs renewed authorisation, we store the refresh token encrypted.

Your tenant’s Enterprise Applications blade shows exactly what you granted.

How we handle the credentials

Our app registrations authenticate with client secrets today. That’s the credential type at the centre of the recent incidents, so this is how we contain the risk.

• We rotate secrets at least every 30 days. If we suspect a compromise, we rotate immediately and start containment rather than waiting for the next scheduled rotation.
• Application secrets live in a managed secret store, never in code, config files or the database.
• Microsoft tokens and integration credentials in our database are encrypted at the field level, and the encryption keys are stored separately. A stolen copy of the database on its own yields nothing usable.
• Only the services that need a credential can read it, plus a small number of authorised staff. Every credential access is logged, unexpected activity alerts the team, and we review privileged access quarterly.

We’re assessing workload identity federation, which removes the stored, reusable secret entirely. It’s the strongest fix for this class of attack, and we’ll share a timeline once we’ve scoped it.

Limiting the blast radius

SuperIT runs one multi-tenant application shared by all customers. That’s the standard model for Microsoft integrations, and it’s also why one stolen credential can matter across many tenants.

Three things limit that today:

1. Consent sets the ceiling. In each tenant, the app can do only what that tenant granted.
2. App instance property lock is on for our production Microsoft 365 and Microsoft sign-in applications. It stops anyone changing sensitive properties on our service principal in your tenant, which blocks the “plant a new secret on a trusted app” move. It won’t stop someone using a credential they’ve already stolen, which is why rotation and monitoring matter too.
3. Credentials are short-lived and the data is encrypted. A stolen secret has a short useful life, and a stolen database alone is useless.

We’re also assessing customer-specific app registrations, so that one credential reaches one MSP’s tenants instead of everyone’s. They add setup work, so we expect to offer them as an option for MSPs who want the tighter boundary, not as the default.

Detection: what you can watch, and what we watch

You can check all of this yourself. Email security@superit.ai for our production application IDs and outbound IP addresses, and use them to watch our app in your own tenants. With them you can alert when:

• our service principal signs in from an unexpected source
• a credential is added to our service principal
• a directory role is assigned to it

On our side, we have monitoring on our own app registrations. It covers anomalous sign-ins, credentials added to our registrations and our service principal gaining a directory role in a customer tenant.

The recent incidents, and our notification commitment

We found no evidence that SuperIT’s applications, credentials or infrastructure were affected by or targeted in the recent vendor credential incidents, and we don’t use the affected integrations. We received no notifications from our alerting and monitoring, and we also manually checked for the published indicators, for unauthorised credential or role changes, for unusual secret access, for infrastructure changes and for database export activity, and found none.

If we confirm or reasonably suspect an incident that could affect your tenant or any connected client tenant, the administrators registered on your SuperIT account get a written notification within 24 hours.

What to check this week, for every vendor app

The MSPs asking us these questions are doing the right thing. Here’s the short version of their review. Run it against every vendor service principal in your client tenants, not only ours.

1. Inventory. List every multi-tenant enterprise app in each client tenant, with its permissions, and remove anything unused.
2. Check directory roles. No vendor service principal should hold Global Administrator or Privileged Role Administrator. Investigate any that do.
3. Alert on change. Alert when a credential is added to a service principal, and when a role is assigned to one.
4. Baseline sign-ins. Ask each vendor for its app IDs and sign-in IPs, and use them to flag service principal sign-ins from unexpected networks.
5. Ask your vendors in writing how they store and rotate credentials, whether they use GDAP, and how fast they’ll tell you about an incident.

Our job is to make SuperIT the easiest vendor on that list to verify. Send questions about any of this to security@superit.ai, or reply to your account contact and we’ll set up a call with our CTO.

Christopher Sale, Co-founder, SuperIT