That’s why Microsoft has introduced security defaults, a simple option that, once enabled on your AAD tenant, does the following: In short, trying to do the right thing becomes more of a chore and, as expected, is something that never gets addressed adequately. Typically, the steps involved here would be distinct and laborious - enable and deploy multi-factor authentication (MFA) here, run some scripts to allow a secure mode of authentication over there etc.

Ideally, organisations wish to ensure that they’re enforcing a “basic” set of options for each cloud identity, to reduce the risk that any attack may pose. With the rise of phishing attacks, the proliferation of breached lists containing, in some cases, millions of user name/passwords and general concerns that a cloud-first IT strategy naturally brings to the table, security becomes a real challenge. Therefore, I thought it might be useful to do a post where I discuss and highlight some of the issues you might face when you enable security defaults for the first time on your tenant. Recently, as our Gold Partner consultancy practice has gone live with enforcing security default policies on Azure Active Directory (AAD), we’ve had to grapple with some interesting “gotchas” that arose.

Azure security defaults