You can use other methods, such as OATH tokens, certificates or FIDO keys: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods

afaik, none of the options are suitable.

otp require either soft or hard generators.

likewise fido requires a possibly virtualized hardware device owning the key.

additionally the above hardly qualify as 2FA and not necessarily safer than proper password implementations.

my own belief is their goal is hardly related with producing a better security.

You can add another verification method, such as receiving a phone call:

• A text message sent to a phone that requires the user to type a verification code.
• A phone call.
• The Microsoft Authenticator smart phone app.

https://learn.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/multi-factor-authentication-microsoft-365?view=o365-worldwide

Sounds like the phone call verification is the only option for you.

you have to enable those methods as an administrator, and be not using certain things, such as security defaults.

Jim.

SMS and phone calls are what you'd have to use for someone without a smart phone.

There are desktop auth for OATH.  It's just not a good idea for an average user.  That defeats part of the separate 2nd factor object for many people, especially anyone susceptible to phishing and keylogging.

what is wrong with FIDO keys using something like a YubiKey device?

A school isn't going to want to distribute hardware devices such as YubiKey.

My company has for many years did the phone call method. The user gets a voice call, they hit # and that's it. It isn't the most secure in the world, not by a long shot. Anyone can answer and hit #. Calls can be rerouted to another device. You can require a pin code, which is somewhat more secure. It is still subject to MFA bombing. 

The SMS method is to receive a code via SMS that you then type into the screen. This also isn't considered secure because SMS messages can be rerouted, and this isn't theoretical. It has happened to many people with crypto wallets, though a school account is less likely to be a target, unless the student or staff also has a nice crypto account.

seems the issue is not to make it safer but rather just working.

an automated responder that presses the pound sign might do though this daring suggestion will probably be met with terrible wrath ;)

i believe mtls is also supported and might not be much harder to configure than a password on the client side. this is not based on experience and i am unsure about both feasibility and simplicity

Any system that is in addition to and not instead of username+password will make the system more secure.

The goal doesn't need to be as secure as possible, or even reasonably secure as possible. Many are happy with more secure than just a password, and rightfully so. A student's email and documents don't typically require the same security as military secrets or crypto wallets.

We were told that the Authenticator App was mandatory as the primary or secondary, but it had to be one of the MFA options. If this is true, can we disable the Authenticator App option for some users without disabling MFA completely?

Also, how does the desktop auth for OAUTH work?

i believe you mean OAUTH. it just works transparently but under the hood, it is a mix of long and short term tokens. the long term tokens are created though regular auth and the shorter term are renewed based on the longer ones. none of this has much direct incidence on your issue unless you manage to hook this to some oauth service that allows password based auth.