How to disable - one‑time password requirement to create bookings using Microsoft booking

The one‑time passcode (OTP) requirement seen by external users during Microsoft Bookings flows is part of Microsoft Entra B2B guest authentication, specifically the email one‑time passcode for B2B guest users feature.

This feature is enabled by default for tenants and acts as a fallback authentication method for guests who cannot authenticate via other identity providers. When enabled, new guest users redeeming invitations or accessing shared resources are prompted to request and enter a one‑time passcode sent to their email.

To remove this OTP step and instead fall back to Microsoft account creation for guests, disable the email one‑time passcode feature at the tenant level:

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
2. Go to Entra ID → External Identities → All identity providers.
3. On the Built‑in tab, select Configured next to Email one‑time passcode.
4. Under Email one‑time passcode for guests, set the toggle to No.
5. Select Save.

Important behavioral points and trade‑offs:

• When email one‑time passcode is disabled, guest users are instead prompted to create a Microsoft account to access shared resources.
• Existing guest users who already redeemed invitations using OTP continue to use their existing method unless the feature is turned off and their redemption status is reset.
• If email one‑time passcode has been enabled and is then turned off, any guest users who previously redeemed via OTP will no longer be able to sign in until their redemption status is reset so they can re‑redeem using another method.
• OTP codes are valid for 30 minutes, and guest sessions last 24 hours before a new OTP is required, which is the designed security posture when OTP is enabled.

From a user‑experience vs. security perspective:

• Keeping OTP enabled provides a secure, passwordless, email‑verified flow but introduces the friction described (especially on mobile where users switch apps to retrieve codes).
• Disabling OTP reduces that specific friction but shifts users to Microsoft account creation and sign‑in, which is a different kind of onboarding friction and still enforces an authenticated identity for access.

For Bookings specifically:

• Bookings uses Microsoft 365 and Exchange as its backend and can require Microsoft 365/Office 365 accounts for booking when the “Require a Microsoft 365 or Office 365 account from my organization to book” setting is enabled on the booking page. In that case, users authenticate via Microsoft Entra ID, and guest flows (including OTP) apply when external identities are used.
• If a lower‑friction, more “public” booking experience is acceptable for certain scenarios, configure the Bookings page so that it is available to everyone with the web page link (not restricted to organizational accounts). In that configuration, users can book without authenticating as guests, which removes OTP entirely but also removes identity‑bound security for those bookings.

A practical mitigation strategy that balances experience and security:

1. For high‑volume, low‑risk bookings where identity assurance is less critical, expose the booking page publicly (no sign‑in/OTP), relying on Bookings’ own scheduling controls and data policies.
2. For higher‑risk or sensitive services, keep the requirement for authenticated users (via Entra ID and, optionally, OTP or Microsoft accounts) and clearly communicate to users why the extra step is required.
3. If OTP friction is the primary concern and Microsoft account onboarding is acceptable, disable email one‑time passcode as described above and monitor user feedback.

References:

• Email one-time passcode authentication for B2B guest users
• Microsoft Entra B2B collaboration FAQs
• Shared Bookings Frequently Asked Questions (FAQ)