Identity verification rollouts tend to hit the same wall, and it is rarely a technical one. The product works, the pilot group is happy, and then someone pulls the numbers on how many people never enrolled. At that point the project stops being a security problem and starts being a people problem.
The users who have not enrolled are not lazy. They are contractors on a three-month engagement, new hires who have not reached the onboarding step yet, alumni who left the institution years ago, warehouse and clinical staff who do not carry a phone on shift, and a stubborn and entirely reasonable group who will not install a company app on a phone they paid for. That last group is usually larger than IT expects and gets quieter about it over time, because they learn that saying so out loud starts an argument.
Every one of those people still needs to reset a password eventually. When they do, they land in the help desk queue, and the help desk queue is the part of the system attackers have gotten good at.
The app requirement is mostly a solved problem now
A lot of vendor content is still selling this as a breakthrough, so it is worth saying plainly. Browser-based verification is no longer unusual. Most serious products in this category can now verify someone through a link or a QR code with nothing to install, and several publish that capability as a headline feature.
If you are evaluating options and a vendor is leading with “no app required,” they are describing table stakes.
So the useful question is not which products avoid the app. It is what still separates them once you get past that, and there are two things that do. One is almost never discussed and catches buyers out repeatedly.
No app and no enrollment are not the same thing
A product can be entirely browser-based and still depend on the user having registered something in advance.
The pattern looks like this. A vendor markets no app download and no new authenticator to deploy, which sounds like there is nothing for the user to set up. Read more closely and the verification runs through a factor the organization already manages: an authenticator app the user enrolled last year, a passkey, a registered device push. Nothing new to install is true. Nothing to enroll is not.
For the large majority of your workforce who enrolled successfully and still hold their device, that distinction does not matter. For everyone in the list at the top of this page, it is the whole problem. They never enrolled, or they enrolled on a phone they no longer have. An app-free product built on their existing enrollment cannot help them, and they route to a human agent, which is where you started.
The question to ask a vendor is not “does this need an app.” It is: what happens to a user who has never registered anything, and what happens to a user whose registered device is the thing they are calling about?
Verification that checks a government-issued ID against an authoritative record at the moment of the request has no such dependency, because nothing needed to happen beforehand. That is the property worth paying for, and it is not the same property as being app-free.
The second gap: which direction you verify
Almost every product in this category verifies the same direction. Someone calls the help desk, and the system confirms the caller is who they claim to be.
There is a second attack that runs the other way. The attacker calls the employee, says they are from IT, and talks them into approving a prompt, entering a device code, or installing remote access software. Mandiant’s M-Trends 2026 found that highly interactive voice phishing was the most common initial infection vector in cloud intrusions during 2025, at 23%, and the second most common across all intrusions, at 11%. Email phishing fell to 6%.
Google Threat Intelligence’s August 2026 reporting on UNC6671 shows what that looks like in practice: attackers calling employees on personal mobile phones while spoofing the company’s own help desk number, with a pretext of an urgent mandate to enable passkeys or update MFA enrollment, then steering them to lookalike pages that intercept the credentials and tokens as they are typed.
No amount of verification on the inbound path helps here, because the employee is the one being called. Covering it requires the reverse control: a way for the employee to confirm that the person claiming to be IT really is. Trusona’s Agent Verify does this with a single-use, time-limited code tied to both the agent and the call, which the employee checks on an internal company page before acting. Because the code is issued per call rather than enrolled in advance, it works for the same users the inbound flow does, including the ones who never registered anything.
Some products cover both directions. Fewer cover both without an enrollment dependency, and that intersection is where the practical difference lives.
Public sector and other constrained environments
Government agencies hit this harder than most, for reasons that have nothing to do with security posture.
Personal device policy is often stricter or governed by collective bargaining, so requiring an app on a personal phone may not be permissible regardless of what the security team wants. Issued devices are not universal, particularly for field, seasonal, and contract staff. Accessibility obligations are enforced rather than aspirational, and a verification flow that only works in one vendor’s mobile app is difficult to defend under them. Procurement cycles also punish anything requiring endpoint software deployment, because that pulls in a second approval track.
A browser-based flow avoids most of this. It runs on whatever device the person already has, needs no endpoint deployment, and is evaluated as a web application rather than as software installed on government hardware.
Worth being direct about the other half of public sector procurement. Authorization programs like FedRAMP and StateRAMP govern which cloud services many agencies may purchase, and they operate independently of whether a product needs an app. An agency subject to those requirements should confirm a vendor’s current authorization status before evaluating anything else, because it determines whether the rest of the conversation can happen at all.
Where this approach is the wrong choice
It does not help against coercion. Someone standing over a legitimate user will pass a document check, because the person really is who the document says.
It inherits whatever is wrong with the underlying identity record. A synthetic identity built on genuine documents years ago verifies successfully, because the record it is checked against is real. Document verification is not a fraud detection system and anyone selling it as one is overselling it.
It requires the user to possess a government-issued ID, which is not universal and skews against exactly the populations that already have the hardest time with institutional systems. Any rollout needs a documented path for people who cannot produce one, and that path needs to be at least as well controlled as the primary flow, or it becomes the new weak point.
And for routine, low-risk requests it may be more verification than the situation calls for. Matching the strength of the check to the risk of the request is the actual design problem.
Comparing the approaches
| Authenticator app | SMS or email code | Existing enrolled factor, browser-based | Document verification at time of request | |
|---|---|---|---|---|
| Requires software install | Yes | No | No | No |
| Requires prior enrollment | Yes | Yes | Yes | No |
| Works for a user who never enrolled | No | No | No | Yes |
| Works when the enrolled device is lost | No | Sometimes | No | Yes |
| Vulnerable to SIM swap | No | Yes | No | No |
| Confirms who the person is, not what they hold | No | No | No | Yes |
| Requires a government-issued ID | No | No | No | Yes |
The third column is the one that gets mistaken for the fourth.
What this looks like in practice
The University of Connecticut runs identity verification inside its NetID password recovery flow through the ATO Protect API. Students, staff, and alumni recover their accounts by verifying with a government ID rather than waiting for the help desk, and finish the reset in under a minute.
The alumni are the detail worth sitting with. They left years ago. They never enrolled a current factor, the phone number on file is stale, and under any enrollment-based model, app-free or not, there is no path for them that does not end at a human agent making a judgment call.
On deployment, our fastest customer went live in 30 minutes. Call center use requires no integration at all, because the agent sends a verification link rather than making the decision themselves.
Frequently asked questions
Why do mid-market IT teams struggle to verify users without app installs?
Most tooling assumes prior enrollment, and mid-market teams rarely have the IAM staff to chase enrollment across contractors, seasonal staff, and people who decline to install a company app on a personal phone. The gap gets handled manually at the help desk, which is the least secure option available.
Can you verify someone’s identity without an authenticator app?
Yes. Browser-based document verification checks a government-issued ID against an authoritative record at the moment of the request, so nothing has to be installed or registered beforehand. Note that some browser-based products still rely on a factor the user enrolled earlier, which is a different thing.
Is app-free the same as enrollment-free?
No, and the difference matters more than the app question. A product can require no download while still depending on a previously registered factor. Ask what happens to a user who has never registered anything.
How do enterprises reduce friction during help desk identity verification?
By removing the prerequisites. Any step a user must complete before an incident becomes a failure point during one. Verification that happens at the time of the request has no such prerequisite.
How can government agencies verify caller identity without extra apps?
Through a browser-based flow that runs on whatever device the person already has. This avoids personal device policy conflicts, works for staff without issued hardware, and is evaluated as a web application rather than as endpoint software. Agencies subject to FedRAMP or StateRAMP should confirm a vendor’s authorization status separately.
Is app-free verification less secure than an authenticator app?
They verify different things. An authenticator app confirms possession of a registered device. Document verification confirms identity against an authoritative record. For account recovery, where the registered device is often the thing being replaced, the second question is usually the one that matters.
What if a user does not have a government-issued ID?
There has to be a documented alternative with the same level of control as the main flow. An unmanaged exception path recreates the problem the system was deployed to solve.
No apps. No pre-registration. Ever.