Updated December 29, 2025
Two-factor authentication (2FA) is one of those controls that feels “basic”… right up until an attacker uses a stolen password to walk straight into your environment. For MedTech teams, that risk isn’t theoretical. The accounts that matter most—QMS access, cloud consoles, code repositories, CI/CD pipelines, vulnerability management tools—are exactly what attackers want.
If you’re deciding between SMS codes and an authenticator app, here’s the practical answer:
- Authenticator apps are generally safer than SMS.
- For high-impact accounts (admins, release/signing, cloud root), phishing-resistant MFA like passkeys or security keys is the better end state.
2FA vs. MFA (quick refresher)
2FA means two different factors are required to sign in (like a password plus a one-time code). MFA is the broader term (two or more factors). Most people use the terms interchangeably, but the point is the same:
A stolen password shouldn’t be enough.
Why this matters in MedTech (beyond “IT security”)
In a regulated product environment, compromised accounts can ripple into places you really don’t want surprises:
- Unauthorized access to source code or engineering tooling
- Changes to build/release pipelines
- Exposure of sensitive data (when applicable)
- Fire drills that derail releases—especially when you’re trying to show you have cybersecurity under control
Here’s a situation we see more often than you’d think: a team locks down the product itself, but leaves high-value “supporting systems” on weaker authentication—like SMS 2FA on an admin account for a cloud tenant, a code repo, or a build system. That’s the kind of gap attackers look for.
Option 1: Authenticator apps (TOTP) — the better default
Authenticator apps (Google Authenticator, Microsoft Authenticator, Authy, etc.) commonly use time-based one-time passwords (TOTP). Codes are generated on the device and change frequently.
Why authenticator apps are safer than SMS
- No SIM swap dependency: If an attacker hijacks a phone number, they don’t automatically get your TOTP codes.
- Less exposure to telecom risks: SMS travels through systems that were never designed to be a secure authentication channel.
- Works offline: Useful for travel, restricted environments, and “no signal” situations.
The operational gotcha people forget
Authenticator apps are only “easy” if you plan for real life:
- phones get replaced
- devices get lost
- people get locked out at the worst possible time
If you standardize on authenticator apps, standardize on recovery too:
- backup codes stored securely
- more than one factor enrolled (where possible)
- a documented recovery process (and a secure way to validate identity)
Option 2: SMS codes — convenient, but easier to attack
SMS 2FA is popular because it’s frictionless. It’s also easier to defeat through:
- SIM swapping/number porting
- SMS interception or rerouting
- Social engineering a telecom provider
Here’s the blunt version: if an account can change something important, SMS shouldn’t be your long-term answer.
When SMS might still be “good enough” (temporarily)
Sometimes you’re stuck with SMS because a vendor hasn’t implemented better options, or the system is genuinely low-risk. If that’s the case, treat SMS as a stepping stone and compensate with:
- strong passwords + password manager
- tight role-based access and least privilege
- login alerts/anomaly detection
- a roadmap to move to stronger MFA
The best answer for high-risk accounts: phishing-resistant MFA
If the account can touch any of the following, you’re in the “don’t mess around” category:
- cloud identity admin
- build/release pipelines
- code signing keys
- update infrastructure
- production access paths
- vulnerability or patch tooling that drives action
That’s where phishing-resistant MFA shines.
Passkeys and security keys
Passkeys (and hardware security keys using modern standards like WebAuthn/FIDO2) are designed to resist common phishing workflows. In plain terms: even if someone tricks a user into typing credentials into a fake site, the attacker still can’t replay the authentication the same way they can with SMS or even many push-based approaches.
This is why many security programs now prioritize phishing-resistant MFA for privileged users first.
A simple decision framework (what to pick and where)
Use phishing-resistant MFA (passkeys/security keys) when:
- Identity provider admins and global admins
- Cloud root/admin accounts
- CI/CD pipeline admin access
- Signing, release, and update infrastructure
- Anything that could affect product integrity or continuity
Use authenticator apps (TOTP) when:
- Standard corporate accounts
- Engineering tools that don’t support passkeys yet
- Third-party systems where app-based MFA is the strongest available option
Avoid SMS when:
- Remote access is involved
- Privileged roles are involved
- The blast radius of compromise is large
(If SMS is your only option, plan to replace it.)
What to document so this holds up in a cybersecurity program
Even though this post is “just” about 2FA, teams benefit when they can point to a simple, repeatable standard that’s actually enforced:
- MFA requirements by account type (privileged vs standard)
- enrollment and recovery procedures
- offboarding steps (this is where gaps hide)
- logging/monitoring for authentication events
- periodic access reviews
- third-party access requirements (especially support vendors)
This is also where cybersecurity stops being a one-off IT task and becomes part of a mature product organization.
Bottom line
- Authenticator apps are safer than SMS for most users and most systems.
- For MedTech teams, the more important move is this: privileged and high-impact accounts should move toward phishing-resistant MFA (passkeys/security keys) wherever feasible.
Need help deciding what MFA belongs where (and how to document it cleanly)?
Blue Goat Cyber can help you build a practical approach that engineering teams will actually follow—and auditors will understand. Schedule a Discovery Session with us today.
FAQs: MFA/2FA for MedTech Teams
Is SMS 2FA ever acceptable for medical device organizations?
Sometimes, usually as a temporary compromise when a vendor doesn’t support stronger options. If you must use SMS, avoid using it on privileged accounts and reduce the risk with least privilege, login alerts, and a plan to migrate to authenticator apps or phishing-resistant MFA.
What MFA should we require for “privileged” accounts?
For accounts that can change configurations, access production, manage identities, approve releases, or touch update/signing infrastructure, use phishing-resistant MFA where possible (passkeys or security keys). At minimum, require authenticator-app (TOTP) MFA and tighten recovery processes.
Is an authenticator app enough for QMS access?
For most teams, authenticator apps provide a solid baseline for QMS accounts—especially when strong passwords, least privilege, and audit logging are enforced. If your QMS accounts can approve changes, manage permissions, or export sensitive data, consider stepping up to phishing-resistant MFA for admins and approvers.
What about suppliers and third-party support access?
Treat third-party access like privileged access:
- Require MFA (preferably phishing-resistant for admin/support accounts)
- Use time-bound access (just-in-time) when possible
- Restrict to the minimum roles needed
- Log and review authentication and remote-access activity
This is a common gap area during audits and incident response. - How should we handle MFA recovery without creating a security hole?
Recovery is where “good MFA” often fails in practice. Use:
- Backup codes stored in a secure vault/password manager
- Multiple factors enrolled (where supported)
- A documented recovery workflow with identity verification
- Clear offboarding steps so old numbers/devices don’t remain valid
Should we use push-based MFA approvals (approve/deny prompts)?
Push MFA can be convenient, but it’s vulnerable to “push fatigue” (users approving prompts they didn’t initiate). If you use push, enable:
- Number matching or stronger verification features
- Conditional access policies (location/device compliance)
- Rate limiting / suspicious prompt detection
For your highest-risk accounts, phishing-resistant options are still the better target.
What’s the simplest policy we can publish internally?
A practical, easy-to-enforce policy looks like:
- Privileged accounts: phishing-resistant MFA (preferred) or authenticator-app MFA (minimum)
- Standard accounts: authenticator-app MFA
- SMS: only allowed when no stronger option exists, with a documented migration plan
- Recovery: backup codes + verified workflow
- Vendors: same or stronger controls than internal users
How does this help with regulatory expectations?
Even when you’re not writing a submission document about MFA specifically, having a clear MFA standard helps you show your organization is implementing consistent security controls across the lifecycle—especially for systems that influence product development, release integrity, and postmarket response.