Somewhere in your building is an application everybody needs and nobody loves. It runs the estimating, or the scheduling, or the general ledger. It was written before smartphones, and its login screen has two boxes: username and password.
You have turned on multifactor authentication everywhere else. Email, file storage, remote access, payroll. Then you reach this one and the vendor says it is not supported. Both obvious responses are wrong. Giving up leaves your most critical system guarded by a password alone. Ripping it out is a two year project you did not budget for. There is a middle path, and it works by changing where the login happens rather than changing the application.
Why the Old App Cannot Do Modern Login
Modern applications do not check your password themselves. They hand you off to a central identity system, which verifies who you are, asks for a second factor, and then tells the application you are cleared. That handoff runs on published standards with names like SAML and OpenID Connect. Every mainstream cloud service speaks one of them.
Older software predates that arrangement. It keeps its own list of users and passwords and checks them itself. There is no handoff, so there is nowhere to insert a second factor. Sometimes the vendor could add support and has not prioritized it. Sometimes the product is a desktop program talking straight to a database file, and the change would be a rewrite.
There is a happy middle case worth checking first. Some older applications do not maintain passwords at all. They ask Windows who you are and trust the answer. If yours works that way, protecting the Windows sign-in protects the app, and you may already be most of the way there. Ask your IT provider which kind you have. The answer changes everything that follows.
The Options, in Plain Terms
If the application genuinely cannot ask for a second factor, make people prove themselves before they ever reach it. Four approaches cover most situations, and they combine well.
- Put a gateway in front of it. A reverse proxy or identity aware proxy sits between the user and the application. It demands a modern login with a second factor, then passes the connection through. The old app never knows anything changed. This is the closest thing to a real fix and usually the first thing we look at.
- Restrict where it can be reached from. Limit the application so it only answers connections from your office network or company managed devices, and require MFA to get onto that network. A stolen password is then useless from a laptop in another country.
- Use a protected jump point. Give people a remote or virtual desktop that itself requires MFA, and let the old application be reachable only from there. Everyone comes through one door, and that door is properly locked.
- Isolate it and shrink the audience. Put the server on its own network segment so a compromised laptop in accounting cannot reach it, then cut the user list to people who truly need it. A 2023 joint advisory from NSA and CISA listed lack of network segmentation among the ten most common misconfigurations, noting it “leaves no security boundaries between the user, production, and critical system networks.”
None of these are exotic. Most businesses already own the pieces through their firewall, identity platform, or remote access tools. The work is configuration and testing, not procurement.
Push the Vendor, and Ask a Better Question
Vendors respond to demand they can count, and most small businesses never ask, so the roadmap never moves. Ask, and ask specifically.
- Name the standard, not the feature. “Do you have MFA” gets you a vague yes. “Does your product support SAML or OpenID Connect for single sign on, and if not, is it on the roadmap and when” gets you an actual answer or a revealing silence.
- Get the answer in writing. Email, not a phone call. If an insurer or client later asks how you handle this system, a dated vendor response is a useful thing to own.
- Ask at renewal. That is when they are listening, and when you have leverage to ask what the migration path looks like if the answer is never.
- Make it a requirement for the replacement. Whenever you replace this system, put modern authentication support in the written requirements. That is how you avoid inheriting the same problem for another decade.
The Honest Calculation on Compensating Controls
Here is the part most articles skip. Compensating controls are real protection, and they are not the same as the thing they replace. A gateway in front of an application is excellent. A network restriction is good. A promise that only three people know the password is not a control at all. Be honest about which you have.
When MFA on the application itself is off the table, these are the things that actually carry weight.
- Password quality matters more here, not less. This is one of the few places a long unique passphrase does real work rather than backing up a second factor. That same 2023 NSA and CISA advisory reported assessment teams cracking over 80 percent of user passwords in one Active Directory environment, which tells you how weak typical passwords are on their own.
- No shared accounts, ever. If four people use one login, you have no idea who did what, and offboarding one of them fixes nothing. Individual accounts are the price of admission.
- Turn on logging and actually look at it. Logins at 2 a.m., repeated failures, activity from someone on vacation. If the application produces a log, someone should watch it. If it does not, watch the server and the gateway instead.
- Review the user list on a schedule. Legacy systems collect accounts. The person who left in 2019 is probably still in there.
- Write down what you accepted and why. One page: what the system is, why MFA is not possible, what you put in place instead, and when you will revisit it. That page earns its keep the first time a cyber insurance application or client questionnaire asks.
It helps to know what you are aiming at everywhere else. NIST’s small business guidance describes MFA as combining “something you know (like a password or PIN),” “something you have (like a smart card or security key),” and “something you are (like your fingerprint or face),” and notes that “FIDO authenticators paired with W3C’s Web Authentication API are the most common form of phishing resistant authenticators widely available today.” For the rest of your systems, our comparison of security keys, passkeys, and app based MFA walks through the tradeoffs.
The Bottom Line
An application that cannot do multifactor authentication is a solvable problem, just not by the application. You move the checkpoint upstream, shrink who can reach the system at all, and document the gap honestly instead of pretending it away. CISA’s multifactor authentication guidance, as published on its site in 2026, describes MFA as a layered approach requiring “two or more credentials to verify a user’s identity for login.” A gateway or a protected jump point restores exactly that layering.
The one thing not to do is leave the oldest, most important system in the building as the only one still guarded by a password alone. That is usually the system with the most valuable data in it, which is a large part of why security is no longer optional for mid-sized businesses.
If you have a system like this and are not sure which option fits, we will take a look and tell you straight. Sometimes the answer is a gateway. Sometimes it is a network rule that takes an afternoon. We work with small and mid-sized businesses across Denton County. Contact us today.
Sources:
Comments are closed