remote access mfa: TOTP, push, passkeys, hardware

You know the problem: passwords get phished, reused, or brute‑forced, and a remote access session is the prize. Multi‑factor authentication (MFA) is the obvious fix — but not all second factors stop the same attacks. This article compares TOTP, push notifications, passkeys (FIDO2) and hardware keys so you can pick what actually reduces risk for your remote‑access fleet.

Quick threat primer — what you need MFA to stop

Before we compare methods, be explicit about the attacker models. Different MFA methods block different capabilities. In remote access I care about attackers who can:

• Steal or guess passwords (credential stuffing, leaked passwords).
• Phish users with a fake login page and capture codes or session tokens in real time.
• Spoof or intercept network traffic (mitm) or control a VPN session.
• Control the user's device (malware that reads authenticators, or a session already established).
• Physically steal a device (phone or hardware token) or perform SIM swaps (relevant for SMS).
• Exploit account recovery or help‑desk overrides to remove MFA.

If you want a deeper mapping of these threats specifically for remote desktop products, see Is Remote Desktop Secure? An Honest Threat Model and Remote Desktop Security: What You Need to Know.

TOTP (time‑based one‑time passwords): what it is and where it stops attack

TOTP (RFC 6238) generates short numeric codes — commonly 6 digits changing every 30 seconds — using a shared secret stored in the server and the authenticator (app or token). Google Authenticator, Authy, FreeOTP and many hardware tokens use TOTP.

• Stops: credential stuffing and password replays. If an attacker only has the password, they still need the current TOTP.
• Partially stops: automated brute force — because codes are short, rate limits are still essential.
• Does not stop: real‑time phishing or man‑in‑the‑middle (MiTM). An attacker who has a login page can prompt the victim for the current TOTP and use it immediately to complete the login. It also fails if the user’s device is compromised and the secret is exfiltrated.

Operational notes: TOTP is simple and broadly supported. But shared‑secret enrollment (QR codes) must be protected: once you’ve given the secret to a user, anyone with that secret can generate codes forever. Backup and recovery policies (re‑provisioning when a phone is lost) are where many organisations weaken security by over‑relying on help‑desk resets.

Push notifications: convenience with social‑engineering risks

Push MFA sends a notification to a registered device asking the user to approve or deny a sign‑in attempt. Implementations vary: some include transaction details (IP, app name), others just show an "Approve" prompt. The server issues a challenge and the device signs or confirms it, then the server grants the session.

• Stops: credential theft on its own — an attacker who only has a password can’t complete the login without approval.
• Partially stops: automated attacks and some MiTM setups if the push is tied to a server challenge.
• Does not reliably stop: targeted real‑time social‑engineering ("approve the login to proceed") and "push‑bombing" fatigue attacks. If an attacker phishes a user and simultaneously hits the real login, many users simply approve to stop the bombardment. Also, push still relies on the integrity of the device; a compromised phone that automatically approves or is controlled by malware defeats this factor.

Practical point: push is high‑conversion and good for general staff, but don’t treat it as phishing‑resistant unless the implementation includes origin/transaction binding and the organisation enforces user training and contextual checks (location, device posture).

Passkeys (FIDO2 / WebAuthn) — real phishing resistance when implemented correctly

Passkeys are the user‑friendly name for FIDO2/WebAuthn credentials. They are public‑key credentials created per relying party (your remote access service). The private key stays in the authenticator (platform or roaming); the authenticator signs a challenge that includes the relying party identifier. Because the signature is tied to the relying party origin, a phishing site cannot reuse it on the real site.

• Stops: phishing, MiTM that relies on credential capture, credential replay, and many automated attacks. If the authenticator is a secure element (TPM, Secure Enclave, or a hardware token that implements FIDO2), the key material is not extractable.
• Partially stops: attacks where the attacker controls the device while the user is present — e.g., if malware on the host can trigger approvals or enroll new credentials via a compromised account recovery flow.
• Does not stop: physical theft when the authenticator is insecure and unprotected by PIN/biometrics, or account recovery abuse where help‑desk can remove the key without proper controls.

In practice, FIDO2/passkeys are the only widely‑available, standards‑based phishing‑resistant second factor. Platform passkeys (Windows Hello, Touch ID/Face ID) are convenient, and roaming hardware keys that implement FIDO2 (YubiKey with FIDO2, Nitrokey FIDO) give the same guarantees with stronger physical separation.

Hardware keys: OTP tokens vs FIDO2 tokens — choose carefully

Hardware tokens come in two flavours: one‑time password tokens (HOTP/TOTP hardware tokens) and FIDO2/WebAuthn tokens. They both have pros and cons.

• HOTP/TOTP hardware tokens: small, cheap devices that display numeric codes. They inherit the same weaknesses as software TOTP: shared secret model, vulnerable to real‑time phishing if the attacker requests the code and uses it immediately.
• FIDO2 hardware tokens: use public‑key cryptography and are phishing‑resistant for the reasons described above. They often require a touch or PIN at the token, which protects against unauthorized use if the token is stolen.

Operational tradeoffs: FIDO2 tokens are preferable where phishing resistance matters. They cost more, require inventory and key‑management policies (issuance, loss reporting, backups). TOTP tokens are cheap and better than nothing, but treat them as a step up from passwords, not a silver bullet.

How each method maps to common remote‑access attack scenarios

Concrete mappings make choices easier. Here are common remote‑access attacks and which factors block them.

• Attacker with only password (credential leak): TOTP, push, passkeys, and hardware tokens all block access.
• Real‑time phishing site that proxies login: TOTP and push are likely to be bypassed because the attacker can relay the code/push, unless the push includes strong transaction details and the user checks them. FIDO2/passkeys block this because the signature is origin‑bound.
• Compromised user device (malware on the PC used to initiate the remote session): MFA helps only if the attacker can’t use the MFA device as well. If malware can read TOTP secrets, intercept push approvals, or trigger a platform passkey without user presence, MFA may fail. Physical hardware keys with touch/PIN provide stronger protection here.
• Help‑desk or account recovery abuse: Any MFA can be bypassed if your recovery processes allow removing factors without strong authentication. Harden recovery workflows and log changes carefully.

Deployment recommendations for remote access

Picking the "best" factor depends on risk tolerance, budget and operational capacity. For remote access (support tools, admin consoles, RDP gateways) I recommend the following baseline:

• Require phishing‑resistant MFA (FIDO2/passkeys or FIDO2 hardware tokens) for privileged accounts and remote‑support operators. These are the highest‑risk roles.
• Allow push or TOTP for general staff, but only with compensating controls: device posture checks, IP/geolocation checks, short session lifetimes and anomalous activity alerts.
• Enforce tight account recovery: multi‑step re‑enrolment that requires proof (device, identity checks), and log every recovery action.
• Keep backup factors: issue a limited number of recovery tokens, and require secondary verification before replacing a lost roaming key.

Operationally, remember that self‑hosting MFA infrastructure is only worth it when you must — for compliance, isolated networks, or strict data‑residency rules. Managed services (including Tenvo’s managed relay) usually cost less once you count patching, certificate renewal, key custody and on‑call time. Tenvo’s managed relay is our default recommendation: we offer native clients for macOS, Windows and Linux, a browser client in public beta, and a multi‑region managed relay. Pricing tiers are Free $0, Lite $2.99/mo and Pro $7.99/mo — the managed option gives you redundancy and zero relay maintenance.

If you do self‑host, accept the operational overhead described in Self-Hosted Remote Desktop: Why, How, and What Breaks and lock down recovery channels aggressively.

Operational realities — backups, enrollment, fraud and user experience

Good MFA design balances security with live operations. A few pragmatic notes:

• Enrollment security: Protect the initial bind step. If enrollment is unauthenticated or only protected by the same username/password, an attacker who can guess credentials can provision a factor for themselves. Require a second channel for enrollment (email confirmation to a corporate address, approval by an administrator).
• Backups and recovery: Don’t email plaintext secrets. For passkeys, provide alternative recovery flows (multiple keys per account, escrowed recovery keys stored with strict access controls). For TOTP, discourage screenshots of QR codes and enforce limited‑time reissues.
• Help‑desk controls: Make revocation and reissuance auditable and multi‑party for high‑privilege accounts.
• Logging and alerts: Log MFA failures, new factor enrollments, and recovery events. Tie them to your SIEM and require human review for abnormal patterns.
• User experience: Platform passkeys reduce help‑desk load. Push is easiest for non‑technical users, and TOTP is useful where devices can’t receive pushes.

If you want a short, practical checklist to set up remote access quickly while keeping MFA sane, see How to Set Up Remote Access in 60 Seconds and our guide on How to Give Someone Remote Access Safely.

Summary: pick defensible, phishing‑resistant MFA for sensitive access

Short version:

• TOTP is better than nothing but fails against real‑time phishing and any attacker who can proxy a session.
• Push adds convenience but is vulnerable to social engineering and approval fatigue unless transaction details and context are enforced.
• FIDO2/passkeys (including FIDO2 hardware tokens) are the only widely‑available standard that reliably resists phishing when deployed correctly.
• Hardware tokens implementing FIDO2 give the strongest protection for high‑risk accounts; keep strict recovery and backup processes.
• Operational overhead (enrollment, help‑desk, backups) is the real cost — and a managed relay/service often reduces that cost compared with self‑hosting unless you have a written requirement to self‑host.

Use phishing‑resistant MFA (passkeys or FIDO2 tokens) for admins and remote‑support operators, keep push/TOTP as pragmatic fallbacks for general staff, and harden recovery and enrollment so MFA can't be trivially removed.

If you want an implementation path that balances operational cost and security, Tenvo’s managed relay removes a lot of running‑cost burdens: native macOS/Windows/Linux clients, a browser client in public beta, multi‑region managed relay, and pricing tiers Free $0 / Lite $2.99/mo / Pro $7.99/mo. Managed relays also simplify MFA enforcement across distributed devices compared with a single self‑hosted relay.

Ready to try? Download the client and enable strong second factors for your critical accounts: Download Tenvo.