CSP Break-Glass Accounts and Passkeys for Customer Tenants

A customer calls at 07:40. Their only Global Administrator left last month, the federation provider is down, and nobody can sign in to the Microsoft 365 admin center. They assume you, their Cloud Solution Provider, can fix it. Can you? And if you can, should you be able to?

That question sits at the centre of CSP break-glass accounts. A single organization designs emergency access once. A partner managing three hundred customer tenants has to design it three hundred times, prove it works in each one, and keep its own technicians from becoming the easiest way into all of them. This guide is for MSP and CSP security leads and owners who need a model that holds up under audit, at scale, and at 07:40.

Our companion article on break-glass design for a single tenant covers the per-tenant mechanics in depth. This one is about the partner layer: who holds what, how technicians authenticate, and how you check three hundred tenants without a spreadsheet.

---

Why do CSP break-glass accounts need a different model?

Partners operate across two identity planes. The first plane is your partner tenant, where your technicians live and authenticate. The second is each customer tenant, which holds the customer's own users, admins, and emergency access accounts. Granular delegated admin privileges (GDAP) is the bridge: per-customer, time-bound access granted through security groups in your tenant.

The two planes fail in different ways. A compromised technician in your partner tenant is a multi-tenant incident, because one identity reaches many customers. A missing or broken break-glass account in a customer tenant is a single-tenant outage, but you will be the one asked to fix it. Good design keeps those failure modes separate:

That last column is Microsoft's own advice. The CSP security best practices say to "avoid creating user accounts in customer Microsoft Entra tenants intended to be used by partners to administer the customer tenant." GDAP exists so you don't have to.

---

How should partner technicians authenticate with passkeys?

Technician identity is the control that protects every customer at once, so it deserves the strongest method you can deploy. For partner technicians, that means device-bound passkeys on FIDO2 security keys, enforced through Conditional Access in your partner tenant. Microsoft's passkey guidance recommends FIDO2 security keys for elevated-privilege users, with Authenticator passkeys as another option.

What Partner Center actually requires

Know the difference between what is mandatory and what is wise:

• MFA for every partner tenant user. The mandatory MFA requirement covers all user accounts, including guests, for Partner Center, the Partner Center API, and delegated administration. Non-Microsoft MFA must emit the amr claim.
• MFA on API calls. Since 1 April 2026, all App+User usage of Partner Center APIs enforces MFA. App-only tokens work only for operations that don't need GDAP roles in the customer tenant, and integrations must use the Secure Application Model.
• CSP authorization requirements. Effective 1 October 2025, the security requirements dashboard lists MFA for all admin users in the CSP tenant, a named security contact, and responding to Partner Center security alerts within 24 hours on average. Microsoft validates these annually in your CSP anniversary month, starting January 2026. Emergency access accounts count toward the admin MFA check.

Phishing resistance is where the documents get vague. The best-practices page asks partners to ensure the MFA method is phishing-resistant "by using passwordless authentication or number matching." Number matching is not phishing-resistant under Entra's own authentication strength definitions. We found no Microsoft primary page that makes passkeys or FIDO2 a hard requirement for partner tenants. Treat that as a floor you should exceed, not a target.

A technician authentication baseline

1. Separate admin identities. Give each technician a dedicated admin account, distinct from their mailbox account. Microsoft's partner security requirements recommend this, plus dedicated, healthy workstations.
2. Device-bound passkeys only. Create a passkey profile for the technician group with attestation enforced and only device-bound types allowed. Synced passkeys "do not support attestation," so an attested profile excludes them. Add an AAGUID allow list for the key models you issue.
3. Bootstrap with a Temporary Access Pass. A one-time Temporary Access Pass lets a new technician register a key on day one. Registration must finish within 10 minutes of sign-in.
4. Enforce with authentication strength. Target the technician group with a Conditional Access policy requiring the built-in phishing-resistant MFA strength. This needs Entra ID P1. Start in report-only to avoid locking out anyone who hasn't registered.
5. Just-in-time elevation. Microsoft recommends Entra ID P2 for admin agents, with PIM and dual custody; see our guide to rolling out Privileged Identity Management. The GDAP FAQ confirms PIM works on the partner security groups used in GDAP.

Attestation has one subtlety worth noting. It gates registration, not sign-in. Turning it on later does not block technicians who already registered a synced passkey, so audit existing methods when you tighten the profile. Our earlier piece on Entra ID passkeys covers profiles in more detail.

Why customer MFA settings don't protect you here

It is easy to assume a customer's cross-tenant access settings add a second check. For GDAP they don't. Per Microsoft's cross-tenant access documentation, "when an external user signs in using GDAP, MFA is always required in the user's home tenant, and always trusted in the resource tenant." MFA registration for a GDAP user is not supported outside the home tenant.

The consequence is blunt. In practice, your partner tenant's MFA policy is the MFA gate on every GDAP session into every customer. If it is weak, every customer inherits that weakness.

One customer-side setting can still hurt you. A customer Conditional Access policy that blocks external users can break GDAP. The fix is to use the "Service provider users" option under "Guest or external users" when customers exclude or target CSPs.

---

How to design GDAP role tiers without standing Global Admin

Microsoft built GDAP around least privilege. The GDAP introduction describes per-customer, time-bound access that the customer must approve, assigned to security groups in your tenant. Partners no longer receive Global Administrator by default.

The hard limits to design around

• Two-year maximum. A GDAP relationship can last at most two years. Permanent GDAP is not possible. An unanswered request expires after 90 days.
• Auto-extend, with one exception. Auto-extend adds six months (180 days) at each expiry until someone ends the relationship. Microsoft is explicit: "You can't auto extend the admin relationship with a Global Administrator role."
• 100 security groups per customer. Role assignments per customer top out at 100 security groups, which matters if you create groups per technician.
• No "every role" shortcut. The FAQ says Microsoft does not recommend replacing Global Administrator with all possible Entra roles. For known issues that truly need GA, request a time-bound GA role instead.

A three-tier pattern

Use three security groups per service line, reused across customers, rather than per-customer groups. Map them to Microsoft's least-privileged roles by task:

Privileged authentication administrator deserves a place in Tier 2 from the start. The GDAP FAQ notes that to reset a locked-out customer admin's password or MFA, you must request that role in the first GDAP relationship. Leaving it out means you cannot help with a locked-out customer admin during an outage.

What about DAP?

GDAP is replacing DAP. Since 25 September 2023, new customer creation grants a default GDAP with specific roles, not DAP. Microsoft's led transition created a one-year GDAP with nine roles and removed DAP 30 days later. Microsoft has not published, on the pages we reviewed, a single final date when DAP disappears for all partners. If any customer still shows DAP, treat it as an open finding and migrate it.

---

Who should own break-glass accounts in customer tenants?

Microsoft does not assign ownership of CSP break-glass accounts. The emergency access guidance is written for the organization that owns the tenant. We found no Microsoft page saying whether the customer or the partner should hold customer break-glass credentials. That makes ownership a commercial and contractual decision you must make explicitly.

Microsoft's technical baseline still applies in every model:

• Two or more cloud-only accounts on the *.onmicrosoft.com domain, not federated or synced.
• Global Administrator assigned as active permanent, not PIM-eligible.
• Passkey (FIDO2) recommended, or certificate-based authentication if PKI exists. The method must differ from what normal admins use.
• Excluded from Conditional Access policies that "block or restrict sign-in," using a dedicated group.
• Credentials kept in "secure, fireproof safes that are in secure, separate locations."

These accounts are also in scope for mandatory MFA. A Conditional Access exclusion does not exempt them, which is why the FIDO2 key matters. SMS will not save you either: Microsoft retires SMS and voice for Global Administrators on 1 July 2027, as covered in our SMS and voice MFA migration plan.

Three custody models

Customer-held. The customer creates both accounts and keeps both keys. This is the most consistent reading of Microsoft's guidance, since the customer owns the tenant and Microsoft advises against partner-use accounts in customer tenants. The weakness is that small customers lose keys, forget combinations, and never test.

Partner-escrowed. You hold the keys in sealed escrow on the customer's behalf. This works operationally, but it creates exactly the standing partner access GDAP was meant to remove. If you choose it, the contract must state that the account belongs to the customer and that you hold credentials only as custodian.

Split custody. Account one's key stays with the customer. Account two's key sits in your sealed escrow, released only on a documented customer request. Neither party alone can lose both. For most managed customers, this is the model we recommend.

Responsibility matrix

R = responsible, A = accountable, C = consulted, I = informed. The customer stays accountable in every column, because the tenant is theirs.

Contract language to adapt

Put the model in writing. Example clauses to review with counsel:

• "Emergency access accounts are the property of the Customer. The Partner holds credentials only as custodian and acquires no rights of use beyond those stated here."
• "The Partner will use an escrowed credential only on written or recorded request from a Customer authorised contact listed in Schedule X, and will notify the Customer within one hour of any use."
• "Every use, test, or alert triggers a joint post-incident review within five business days."
• "On termination, the Partner returns or destroys all escrowed credentials and the Customer re-registers new keys."

---

How to run key logistics across hundreds of tenants

Hardware keys are physical inventory, and CSP break-glass accounts multiply that inventory by every customer. Treat them like it.

Keep a key register. Record serial number, key model and AAGUID, customer tenant, account UPN, holder, storage location, seal number, and last test date. Store it separately from the keys themselves.

Seal and log. Place each escrowed key and its PIN in a numbered, tamper-evident bag. Record the seal number in the register. A broken or changed seal number is an incident, even if nothing else looks wrong.

Separate locations. Microsoft's guidance says separate, secure locations. For split custody, the separation is built in. For partner-escrowed accounts, keep account 1 and account 2 keys in different safes, ideally different sites.

Never let them expire. Microsoft warns that emergency credentials must not expire or fall into automated inactivity cleanup. Exclude break-glass accounts from any stale-account automation you run across customers.

Rotate on events. Re-register keys and change safe combinations after staff departures, after any real use, and when a customer leaves. Test at least every 90 days, after IT staff changes, and when subscriptions change, as Microsoft's emergency access page specifies.

---

Monitoring break-glass sign-ins at scale

You need two kinds of visibility: posture across all tenants, and real-time alerts on specific accounts.

What Microsoft 365 Lighthouse gives you

Microsoft 365 Lighthouse is free for CSP partners and is strong for posture. It surfaces MFA, self-service password reset, and risky-user reporting, plus a default security baseline and deployment journeys. Know its limits before you rely on it:

• Customers need GDAP or DAP, at least one eligible paid subscription, and no more than 2,500 licensed users.
• The customer must be in the same geographic region as the partner.
• MFA and risky-user reports need Entra ID P1 or higher.
• Ineligible tenants get only limited features, such as GDAP management, user search, tagging, and service health.

Lighthouse is a posture console. For a Severity 0 alert the moment a break-glass account signs in, use Log Analytics.

Sentinel and Log Analytics through Azure Lighthouse

Azure Lighthouse delegates Azure RBAC over customer resources. Partner users never sign in to the customer tenant and get no Entra permissions there. It is also decoupled from GDAP: severing one doesn't affect the other.

The pattern: the customer streams Entra sign-in logs to a Log Analytics workspace in their own subscription. You hold an Azure Lighthouse delegation to that workspace and run detections from your Sentinel instance. Check Microsoft's licensing prerequisites for exporting sign-in logs per tenant before you commit.

Microsoft's emergency access page provides the base query, alert threshold (greater than 0), and severity ("0 – Critical"). At partner scale, drive it from a list of account IDs. This example is illustrative and adapted from Microsoft's single-tenant sample:

// Illustrative: alert on any sign-in by a registered break-glass account
let BreakGlass = datatable(TenantName:string, UserId:string)
[
    "Contoso", "00000000-0000-0000-0000-000000000001",
    "Contoso", "00000000-0000-0000-0000-000000000002",
    "Fabrikam", "00000000-0000-0000-0000-000000000003"
];
SigninLogs
| where UserId in ((BreakGlass | project UserId))
| join kind=inner BreakGlass on UserId
| project TimeGenerated, TenantName, UserPrincipalName, UserId,
          IPAddress, ResultType, ResultDescription

In production, replace the inline table with a Sentinel watchlist fed from your key register. Every alert, drill or not, gets a post-mortem.

---

How to automate break-glass drift checks with Microsoft Graph

CSP break-glass accounts drift. Someone adds them to a CA policy, removes a key, or a new GA appears. A scheduled check catches this before the 07:40 call.

The approach is a multi-tenant app registration in your partner tenant, consented in each customer tenant with read-only Graph application permissions. Microsoft's partner pages we reviewed do not spell out the consent mechanics for app-only access in customer tenants, so validate yours against the Secure Application Model and get customer approval. Mandatory MFA does not apply to workload identities or Graph APIs, so certificate-based app-only access keeps working.

The sample below is illustrative and untested. It assumes Directory.Read.All, Policy.Read.All, and UserAuthenticationMethod.Read.All application permissions, and a certificate in the local store.

# ILLUSTRATIVE SAMPLE - review, test, and adapt before use.
$tenants = Import-Csv .\customers.csv   # TenantId, Name, BreakGlassUpns, EAGroupId
$gaRoleTemplate = '62e90394-69f5-4237-9190-012177145e10'  # Global Administrator

foreach ($t in $tenants) {
    Connect-MgGraph -ClientId $env:DRIFT_APP_ID -TenantId $t.TenantId `
        -CertificateThumbprint $env:DRIFT_CERT_THUMB -NoWelcome
    $findings = @()

    # 1. Count Global Administrators (Microsoft advises fewer than five)
    $gaRole = Get-MgDirectoryRole -Filter "roleTemplateId eq '$gaRoleTemplate'"
    $gaMembers = Get-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id -All
    if ($gaMembers.Count -ge 5) { $findings += "GA count $($gaMembers.Count)" }

    foreach ($upn in $t.BreakGlassUpns -split ';') {
        $u = Get-MgUser -UserId $upn -Property Id,AccountEnabled,OnPremisesSyncEnabled
        if (-not $u.AccountEnabled) { $findings += "$upn disabled" }
        if ($u.OnPremisesSyncEnabled) { $findings += "$upn is synced" }
        if ($gaMembers.Id -notcontains $u.Id) { $findings += "$upn not active GA" }
        $keys = Get-MgUserAuthenticationFido2Method -UserId $u.Id
        if (-not $keys) { $findings += "$upn has no FIDO2 key" }
    }

    # 2. Enabled CA policies should exclude the emergency access group
    Get-MgIdentityConditionalAccessPolicy -All |
        Where-Object { $_.State -eq 'enabled' -and
            $_.Conditions.Users.ExcludeGroups -notcontains $t.EAGroupId } |
        ForEach-Object { $findings += "CA '$($_.DisplayName)' lacks EA exclusion" }

    [pscustomobject]@{ Tenant = $t.Name; Findings = $findings -join '; ' }
    Disconnect-MgGraph | Out-Null
}

The CA check is deliberately strict. Report-only policies need no exclusion, so tune it to your own policy set. On the partner side, also review GDAP relationships for expiry dates and any GA role on an auto-extend request. Microsoft's FAQ links a beta Graph API for this; confirm its current status before you build on it.

---

Onboarding and offboarding runbook

Onboarding a customer

1. Send a GDAP request with Tier 1 and Tier 2 roles, including Privileged authentication administrator. Request Tier 3 GA separately and time-bound.
2. Agree the custody model in writing and record named authorised contacts.
3. Create two cloud-only break-glass accounts, assign permanent GA, and register FIDO2 keys in a witnessed session.
4. Add both to the emergency access exclusion group. Check every block or restrict policy.
5. Configure sign-in log export and the Azure Lighthouse delegation. Add account IDs to the watchlist.
6. Register keys and seals, then run the first sign-in test and close it with a short report.

Offboarding a customer

1. Return or destroy escrowed keys per contract, with a signed receipt.
2. Ask the customer to re-register new keys on both accounts and confirm by test.
3. Terminate GDAP relationships and remove the Azure Lighthouse delegation.
4. Remove the tenant from the drift-check list and watchlist. Archive the register entries.

The customer can always see and terminate your relationships under Settings > Partner relationships in their admin center. Make offboarding something you lead, not something they discover.

---

What to do when a customer is locked out

Run this playbook in order. Our Microsoft 365 outage runbook covers the wider communications plan.

1. Confirm identity and authority. Verify the caller against the named contacts in the contract. Lockout calls are a social engineering favourite.
2. Try customer-side break-glass first. If the customer holds a key, walk them through sign-in from a secure workstation.
3. Use GDAP if it fits. If a normal admin is locked out and you hold Privileged authentication administrator, reset their password or MFA methods under PIM, with the customer on the call.
4. Release escrow only on request. For partner-escrowed or split custody, log the request, break the seal with a witness, record the seal number, and notify the customer.
5. Escalate to Microsoft when needed. If mandatory MFA enforcement is the blocker, a Global Administrator can ask Microsoft Support to temporarily lift it. Plan for the customer, as tenant owner, to lead any tenant recovery case.
6. Close out. Rotate any used credentials, re-seal, update the register, and hold the joint review.

---

How mature is your multi-tenant break-glass program?

Score your CSP break-glass accounts program honestly.

---

Related Articles

• Entra ID Privileged Identity Management: Rolling Out Just-in-Time Admin Access
• Build the Microsoft 365 Outage Runbook You Didn't Have
• Conditional Access Gap Analysis: Finding and Fixing Coverage Holes with What If