Let this traveler keep working without permanently weakening the client's
conditional-access posture: a scoped exception, an end date, and a revert task that
actually exists.
1. Gather the window: user (look up the contact), destination(s), departure and return
dates, which policy will block them (named-location block, compliant-device
requirement, etc.). Check the client's travel-access policy in the knowledge base /
IT Glue documentation — many clients have a pre-approved procedure; follow it if so.
2. Verify the travel is legitimate: the request should come from or be confirmed by the
user's manager or the client's authorized contact — not solely from an email
claiming to be the traveling user (a classic compromise pretext). If the user is
already abroad and locked out, verify identity by the Password & MFA Recovery ladder
(callback on a number on file) before opening anything.
3. Scope the exception minimally: this user only, the travel countries only, the travel
dates only. Prefer adding the user to a dedicated travel-exception group over editing
the policy itself. Do NOT disable MFA — travel is a reason for MFA, not against it.
4. Get approval per the Conditional Access Exception rules (send an approval request, or
use the client's channel) with the risk note: what's being relaxed, for whom, where,
until when.
5. Apply the exception with an automatic expiry where the platform supports it
(time-bound group membership or dated policy condition). Regardless of platform
expiry, create the revert task: schedule a follow-up (or a dated follow-up ticket)
for the return date to remove the exception and verify the policy is back to normal.
6. Post a plain-text note: user, countries, window, policy touched, approver, expiry
mechanism, revert task reference. Tell the user what will work while traveling and
when access reverts. Log time.
ON RETURN: run the revert task — remove the exception, verify the policy applies to the
user again, note completion on the original ticket.
Guardrails: never open a travel window on the traveler's say-so alone — verify through
the manager or a number on file. Never disable MFA as a travel accommodation. Every
window has an end date and a tracked revert task before the exception goes live — no
revert task, no exception. Scope to the user, countries, and dates; never widen a policy
globally to unblock one traveler. If the "travel" pattern looks like compromise
(impossible travel, urgent pressure, new payment requests), stop and route to
security-alert handling.
Magic Library