TOTP implementation is incomplete
The data contained in one of your QR codes for setting up 2FA via TOTP decodes to something like this:
otpauth://totp/screenconnect?secret=123456789ABCDEF
On the other hand, if you enable 2FA on a service like Gmail, the data in their QR code decodes to something like this:
otpauth://totp/Google%3Ausername%40gmail.com?secret=123456789ABCDEF&issuer=Google
That's URL encoded, human readable is this:
otpauth://totp/Google:username@gmail.com?secret=123456789ABCDEF&issuer=Google
It's pretty plain that you guys are omitting the account information and instead are doing the bare minimum to even make the TOTP QR code work.
This needs fixed. Here is more documentation on the subject: https://github.com/google/google-authenticator/wiki/Key-Uri-Format
So why is this a problem? The account information helps TOTP apps distinguish between - you guessed it - different accounts! I have two ConnectWise Control instances setup for two different companies, and of course my logins and 2FA are different between them. However, since the account information isn't part of the URL contained in your QR code, Microsoft Authenticator doesn't have a way to distinguish them. It thinks I'm trying to update my 2FA for "screenconnect" and obliterates my 2FA for the other account. Thus it is currently not possible to have multiple accounts for ConnectWise Control setup in Microsoft Authenticator. I'm forced to use two different Authenticator apps instead. Also, new users won't be aware of this (like I wasn't!) and they may lock themselves out. Actually, it's very easy to create a malicious QR code to erase your 2FA code from Microsoft Authenticator. Just try setting up 2FA with Microsoft Authenticator in control, then scan this code:
Boom, your 2FA for ConnectWise Control is now obliterated, and I didn't even need to know your username to do it. See how bad this is?
You might say "just use Google Authenticator instead of Microsoft Authenticator" - that's not a solution. There is no method to backup your 2FA codes when you migrate to a new phone, or (worse) break or lose your current phone. A phone lasts, what two years? So you're guaranteed to lose access to your accounts if you use Google Authenticator. On the other hand, Microsoft Authenticator provides backup capability and it actually works.
Weird, I received an email about an update to this and it's not showing..
With that in mind, I agree that the URL format isn't consistent BUT stopping at a 10% solution vs. even a solution that would work 90% of the time...and since SC could control the generation of the QR and the URL format they are using they could update it as the "spec" changes as they release new SC updates.
There is also no reason why SC's enrollment process isn't like that of any other solution, where they could dynamically provide the URL of the SC instance that is generating the code and guide the user through an enrollment process vs. sending them to either a page buried in the university or making everyone create/host their own solution.