Forum Discussion
Self-service MFA changes not possible for users
Spent a fairly long time investigating this ourselves and with MS support regarding what is clearly a bug regarding MFA, however fobbed off yesterday with a "By Design" response!
In a nutshell - tenancy has MFA enforced for all users when off-site via conditional access. Works very well indeed UNTIL a user has a problem such as losing or damaging their MFA device. This shouldn't really matter as in the eyes of any layman, once on site they should be able to log on and change their MFA details as they can log on otherwise without issue. However, clicking through to their security info to do this forces them to authenticate, even on site. The only possible way for them to have their details changed is to ask an admin to reset it for them.
It's 2021, we live in a self-service world yet this is deemed "by design". I can't be alone surely?
- This additional verification when performing certain actions, such as updating security details, is indeed by design. And it's the same with pretty much every other cloud service. User can ask their IT folks to reset their MFA status, and admins need to plan accordingly (a break-glass account).
- That isn't correct though is it? It isn't the case for Gmail, it isn't the case for any of my financial accounts, online storage accounts or utilities. If MFA is not enabled on site, why is it suddenly enforced when changing a detail they would otherwise have access to if MFA was entirely disabled? The user has already been vetted securely via conditional access and local AD so surely there must be an option provided to bypass this? We "only" have 1300 users - is this also the case for larger establishments with tens of thousands and minimal IT teams?
- I sympathize, but I think you've framed this in a way that might not be the best comparison.
Changing an MFA credential/token is arguably an administrative act, even if the user is doing it. My experience with Google has been very similar in circumstances like the one you're describing. I don't think you can compare this with a circumstance where "MFA was entirely disabled" because even your own situation doesn't sound like that. That's before we even get to questions of whether it's advisable to run with no MFA at all. Architecture is best derived from your own threat model, but these days, it's difficult to make the case that a username/password tuple is a robust credential for anything important. Part of why you'll find pretty much any competent cloud service provider requiring a little additional assurance for credential administration is that credential theft is by far the primary risk to cloud service users (and operators). MS has written volumes about that, but they're not unique.
