A related discussion can be found, specifically addressing the security implications of using only TOTP for single-factor authentication However, in my view, using a TOTP code from a Google Authenticator on a mobile device effectively constitutes two-factor authentication. Provided that every user secures their phone with a PIN – which is "something they know" this would represent the first factor. Possession of the device itself becomes the second factor, "something you have." Therefore, employing TOTP alone instead of passwords should be considered as two-factor authentication, shouldn't it? With the exception of the first registration step, where the user is granted the secret seed for TOTP generation.
In your example you can indeed say that is 2FA. But the possible (and very likely) issues are:
- unless enforced by some company policy or by phone owners/vendors, you cannot assume that a PIN code or preferably a stronger security layer will be in place to access the device
- unless secured independently the TOTP app (or SMS, phone call..) and the received codes can be read as soon as someone has opened/unlocked the device
This means essentially two things:
- with TOTP only you would most likely end up in a single-factor authentication, which is "something you have" = the device
- and with PIN+TOTP you would end up at best with a "fairly" secure 2FA solution (far from industry best practices)
Now even if this "fairly" secure 2FA solution quite ressembles to your debit card and its 4-digit PIN, I would like to emphasize that you generally only have 3 attempts at pin code in this case ^^, cards have limits/caps, your card is not connected to the Internet, banks have safeguards in place for you AND you can call "Card Stop" any time ;) Just to cite a few mitigations your phone doesn't have (standard or by default).
However what you describe in the end (and maybe want) is essentially the password-less trend that is being introduced here and there. The major difference is that modern passwordless solutions will ensure that both factors provide satisfactory security (while keeping the solution convenient). Therefore they will focus instead typically on:
- authenticating the user with modern biometrics
- and coupling authentication with registered device(s) such as an hardware token, laptop/phone or a smart card... often having the device itself to sign back the response or challenge (using asymmetric keys, public-key infrastructure).
- while often providing additional safeguards and protections
Provided that every user secures their phone with a PIN – which is "something they know"
If you're in an environment where you can guarantee this then you might be able to make that argument. But generally you can't really make this kind of assumption, any more than you can can claim that a password could be 2FA if the stores it on their phone, because the phone is "something you have".
In order to be truly two-factor authentication, both factors must be required every time. But in practice this isn't true of phones; they can be stolen while unlocked. Nor is it true of TOTP, in at least some cases; TOTP keys tend to end up in various places such as email accounts, browser caches, phone backups, and so on, such that a even if the user only ever interacts with the TOTP secret via their phone, an attacker might be able to do it in a way that doesn't involve the phone (and thus doesn't require the phone's memorized or biometric auth credential) at all.
What you describe is strikingly similar to the current trend of using "passkeys" as single-factor authentication (often not even allowing a second factor to be added), with the sole exception that passkeys are, in fact, inherently more secure than TOTP. In both cases, if you do it right (maintain physical control of your devices at least while they're unlocked, don't store the secrets anywhere outside the secure device) and the server implements the auth system correctly (don't use predictable secrets, don't allow resetting the credential using a less-secure method), then they are like two-factor systems even though in practice only one factor is required. However, in practice, that's not how things work. Just as password managers have been offering to store TOTP secrets and generate the codes on demand (sometimes with autofill) in your desktop browsers for years now, so have they moved on to storing and automatically handling passkeys, despite neither their storage nor their authentication living up to the intended security model for passkeys. That's not to say putting passkeys (or TOTP secrets) into a password manager is insecure, it's just not as secure as their intended use case. It might still be sufficiently secure (probably is more secure than what the vast majority of users do today).
Also, note that there are already a handful of sites/services - some of which handle considerable amounts of their users' real money - that can be authenticated to solely via SMS. The same arguments you make for TOTP would seem to apply there as well - the code goes to a Thing You Have, and you have to supply a Thing You Know (or Are) to unlock the phone and read the message. But in practice SMS just isn't secure enough for that, in part due to user behavior; they sync them across multiple networks, they display them on the lock screen of the phone, etc. SMS is in fact inherently even less secure than TOTP, but arguably by a smaller margin than TOTP is less secure than passkeys, and it's already pretty questionable to treat those as categorically adequate single factors.