Adatum: Double MFA Prompts, Unverified Guests, and a 15-Minute Revocation Clause
Adatum collaborates with 30 partner tenants. Guests redeem invitations either with a work account from the partner or with a personal Microsoft account, and 40 percent of guest objects show an unverified personal email address, which the auditor flagged as an identity-assurance gap. Adatum's Conditional Access policy requires MFA for all guests, and partners complain about being prompted twice because their own tenant already enforces MFA. Twelve partner tenants accidentally block Adatum's own users with their own Conditional Access policies. A new contract clause requires Adatum to remove a partner's access within 15 minutes of termination.
1. Stop the double MFA prompt for partners who already enforce MFA, without leaving a hole for guests who redeem with a one-time passcode.
Read the worked answer
Use inbound MFA trust in cross-tenant access settings, per partner organization.
Add each verified partner tenant to the inbound cross-tenant access configuration and enable Trust MFA from that organization. Keep the Conditional Access policy requiring MFA for guests in place; when a guest authenticates in their home tenant and that tenant emits the MFA claim, the trust satisfies the policy and the user is not prompted again.
Conditions and caveats that decide whether this is safe:
- Trust only works when authentication actually happens in the partner's Entra tenant. A guest who redeems with a one-time passcode or a personal Microsoft account never gets the partner's MFA claim and will still be prompted - which is the correct behaviour, so do not weaken the blanket policy to fix the complaint.
- Verify the partner really enforces MFA for all users, not just for administrators. Trusting a tenant that only enforces MFA for privileged roles creates a hole.
- Apply the same reasoning to device trust (compliant device / hybrid join) before enabling it - a partner with weak compliance enforcement becomes your weak link.
- Use the external user type condition if you need a separate policy path for guests versus
b2bDirectConnectusers.
The 12 partner tenants blocking Adatum are the mirror image: that is their inbound policy on Adatum's outbound side. It is fixed by negotiation in their tenant or by Adatum adjusting outbound settings - you cannot override another tenant's policy from yours.
2. The auditor's finding is that 40 percent of guests have unverified personal email addresses. What changes, and what does the fix not prove?
Read the worked answer
Diagnose precisely. Query the guest objects and group by identityProvider. Guests created through one-time passcode show up as email-verified only; personal Microsoft accounts are Microsoft-verified but not employer-verified. Neither constitutes proof of employment at the partner.
Changes:
- Restrict guest invitations with a domain allowlist so only partner corporate domains can be invited, and restrict who may invite guests.
- Move partner onboarding to entitlement management access packages with connected organizations, so admission is tied to a verified partner tenant rather than to an email address. A user who redeems through their partner tenant is authenticated by that tenant - that is the identity assurance the auditor is asking for.
- Remediate the existing 40 percent: identify OTP-based guest objects, re-onboard the legitimate ones through the access package (which creates a properly tenant-backed object), then delete the stale OTP objects. Do this in batches with sponsor confirmation, not in a single sweep.
What the fix does not prove: a personal Microsoft account at contoso-partner.com is not proof the person works at the partner, and even a correctly tenant-backed guest is not proof of continued employment. Identity assurance for guests must be re-established on a cycle - sponsor attestation in an access review, or expiry-driven re-onboarding - not inferred once at invitation time.
3. Design revocation so Adatum can genuinely remove a partner's access within 15 minutes of contract termination.
Read the worked answer
Be honest about the token model, then engineer to the SLA.
Layer 1 - block the organization: in cross-tenant access settings, set the partner to Blocked on inbound (and outbound if needed). This stops any new token acquisition immediately.
Layer 2 - kill existing sessions: revoke refresh tokens for the affected guest objects (Revoke-MgUserSignInSession), and remove their access package assignments and group memberships. Deleting the guest objects is the blunt instrument that also removes the identity entirely.
Layer 3 - the hard part: already-issued access tokens stay valid until they expire (about an hour by default). Refresh-token revocation does not shorten that. The mechanism that closes the gap is continuous access evaluation: for CAE-capable clients, token revocation, account disable, and account deletion are evaluated in near real time (minutes), which is what makes a 15-minute SLA achievable. So: do not configure Conditional Access in a way that disables CAE, and for non-CAE clients use a short sign-in frequency so re-authentication happens sooner.
Layer 4 - outside Entra: anonymous or direct sharing links in SharePoint/OneDrive, and any partner-side caching of data, are not revoked by an Entra action. Identify and remove those separately.
Finally, make it executable: a runbook that maps partner tenant ID → guest object IDs → the commands above, rehearsed quarterly against a test partner with the clock running. An SLA you have never measured is not an SLA.