We'd start with administrator accounts, because an administrator can change settings that affect many accounts at once. We'd then extend the requirement to every user account, since a stolen password reaches whatever that account can reach.
Teams shows what a stronger requirement looks like. Its sign-in runs through Microsoft Entra ID, and Entra has a control called an authentication strength. It lets an administrator say which sign-in methods are accepted for a given resource. The built-in phishing-resistant strength accepts a FIDO2 security key, Windows Hello for Business or a platform credential, and multifactor certificate-based authentication. A password followed by a text message or a push notification satisfies ordinary multifactor authentication. It doesn't satisfy that strength.
The difference is in how the methods work. A texted code can be typed into a fake sign-in page and passed along to the real one. Microsoft describes the phishing-resistant methods as requiring an interaction between the authentication method and the sign-in surface, so there's no code for the user to hand over.
Two conditions come with this control. Authentication strengths are part of Conditional Access, which requires a Microsoft Entra ID P1 license. And the policy is evaluated after the initial authentication, so it sets a requirement for reaching the resource and doesn't change the first password prompt. It's a rule about how someone must sign in to get to the admin tools.
Other UCaaS services have their own sign-in systems, and the options depend on the product and the plan. The thing to find out is whether the admin portal can require a second factor, and which factors it accepts.