Forum Discussion
Security Best Practices for Bookings Page's Mailbox Objects in Entra ID
Hi,
are there any recommendations / best practices for hardening the user objects that are created in Entra ID when I create a new Microsoft Bookings page?
Unlike regular shared mailboxes, the sign-in is enabled by default, I can simply reset the password, sign in via Outlook Web and see the Microsoft Bookings calendar. Bad actors could brute force this sign-in, register the MFA authentication method of their choice and gather data of the customers that used my public bookings page.
What is the recommeded way to handle these objects in Entra ID? Conditional Access settings? Azure Monitoring alerts for sign-ins? Defender alerts for when an inbox rule is created?
Kind regards,
Yasemin
You can disable the account if you're too worried, it shouldn't affect the Booking functionality.
4 Replies
For Bookings mailboxes, the safest approach is to treat them like service accounts. Disable interactive sign-in, block all authentication methods, and allow access only through the Bookings service. If sign-in must remain enabled, apply a strict Conditional Access policy (location/device restrictions), enable sign-in alerts, and monitor inbox-rule creation via Defender. This prevents brute-force attacks and stops bad actors from registering MFA or accessing customer data.
You can disable the account if you're too worried, it shouldn't affect the Booking functionality.
Confirmed - works for us too
VasilMichev​ Thank you, I tested it and it works. For some reason I assumed it would break the Booking page somehow.
