You are preparing a cross-tenant access change for a technician to execute in Entra. You scope the trust, decide the trust claims, and write the rollback; the tech reads current state and applies the change. Never mark the change as applied on intention, and never invent the current configuration — verify against Microsoft's current cross-tenant docs, as this settings surface changes frequently.
1. Intake — scope the actual need; read the ticket for context. Which partner organization (their tenant domain), which direction (their users into the client's tenant = inbound; client's users into theirs = outbound), which of the client's users/groups and apps are in scope, and for how long (project-bound or ongoing). "Everyone, everything, forever" is a red flag to push back on, not a requirement to implement.
2. Docs and current state. Check the client's documentation and the knowledge base (skip gracefully if absent) for the client's external-collaboration standard. Tech reads the current cross-tenant access defaults and any existing org-specific entries — a partner may already be configured, and the fix is adjusting scope, not adding a duplicate.
3. Prefer an org-specific entry over loosening defaults. Add the partner tenant as a named organization in cross-tenant access settings and scope inbound access to the specific users/groups and applications requested. Never change tenant-wide cross-tenant defaults to satisfy a single-partner request — org-specific settings exist for exactly this; tenant-wide default changes affect every current and future external org and need their own justification and approval, separate from this request.
4. Decide the trust claims deliberately. The double-MFA fix is trusting MFA claims from the partner's home tenant. That is a real trust decision: the client is accepting the partner's MFA quality as their own. Reasonable for a known, managed partner; state it plainly in the approval. Trusting compliant-device or hybrid-join claims is a bigger step — only when the partner's device management is known and the client's CA policies depend on it; default to NOT trusting device claims. MFA-trust and device-trust decisions are named explicitly in the approval — they must never ride along silently in "set up the partner access."
5. Pair with invite hygiene. If the client wants domain restriction, set the collaboration allow/deny list to the approved partner domains — an allowlist is the durable posture; a denylist is whack-a-mole. Confirm this doesn't strand existing guests from other domains (cross-reference the guest-access-audit skill for who is already inside).
6. Approval gate. Send an approval request to the client's documented authority with: partner tenant, direction, scoped users/groups/apps, trust claims accepted (MFA yes/no, device claims yes/no), duration/review date, and the rollback — remove or restrict the org-specific entry, which cuts the partner's access cleanly without touching individual guests. Ongoing collaborations get a review date; project-bound ones get an end date and a tracked removal — trust without expiry is the failure mode this skill exists to prevent.
7. Verify and document. Test with one partner user: access works, and the MFA experience matches the decision made. Document what/why/when/rollback: leave a plain-text note with partner org, direction, scope, trust decisions, approver, review date, rollback steps. Store the full configuration record in the client's documentation.
When in doubt about the scope, direction, or a "trust everything" request, do nothing and escalate to the client's documented authority.
