Locking Down Service Accounts: Passkeys and the Retirement of SMS Verification
Every service tech has a mental map of where a dental X-ray system can fail: the sensor cable, the generator’s high-voltage section, the collimator alignment, the tube head bearings. What rarely makes that map is the login — the account a technician or practice uses to reach imaging portals, remote-diagnostics dashboards, ticketing systems, and the email that ties it all together. It is a component like any other, and right now it is running on a part that is being discontinued. Microsoft is making passkeys the default sign-in and retiring its texted and spoken verification codes on February 1, 2027. This is a good moment to service that account the way you would service any aging assembly: diagnose it, understand the root cause, replace the failing part, and set a prevention schedule.
Symptom: the account that everyone trusts and no one inspects
The presenting symptom is familiar. Staff and technicians sign in with a password plus a code texted to a phone, and everyone assumes that is “secure enough.” But these accounts often touch protected health information — radiographs pulled for a repair verification, patient records visible in a shared mailbox, portal access to a practice’s imaging archive. A single compromised login can expose all of it, and because the account works fine day to day, the weakness never shows up on anyone’s checklist. It is the electrical intermittent of IT: invisible until it strands you.
Diagnosis: why the texted code is the failing part
Put the texted code on the bench and it fails three tests. First, phishing: a counterfeit sign-in page asks for the code and relays it to the real site in real time — the code does exactly what it is supposed to, for the wrong person. Second, replay and interception: a code that travels can be caught in transit. Third, SIM-swap: the phone number the code depends on can be transferred to an attacker’s SIM by social-engineering the carrier, at which point the codes arrive on their device, not the technician’s.
The root cause behind all three is the same design flaw: a verification code is a shared secret in motion. Anything that moves can be intercepted, mimicked, or redirected. No amount of policy tightening fixes a part that is fundamentally the wrong part for the job.
The replacement part: how a passkey works
A passkey is a cryptographic credential bound to a specific device — a phone, a laptop, or a dedicated hardware security key — and unlocked locally with a fingerprint, a face scan, or a PIN. The device holds a private key that never leaves it. When you sign in, the device proves it holds that key without transmitting the secret itself, and the proof is cryptographically tied to the genuine site’s identity.
Run the same three tests and the passkey passes all of them. There is no code to type into a fake page, so phishing has nothing to harvest. Nothing reusable crosses the network, so interception yields nothing. And there is no phone number in the loop, so a SIM-swap is irrelevant. This is what “phishing-resistant” means in practice — not that attacks are harder, but that the usual attacks have no surface to grab.
The service procedure: enrolling passkeys
The replacement is straightforward and can be done per person in a couple of minutes:
- Sign in to the account’s security settings page (for Microsoft accounts, the sign-in / security-info page).
- Select add a sign-in method and choose passkey or security key.
- Confirm on the device with a fingerprint, face scan, or PIN to create the passkey.
- Enroll a backup — a second passkey on another device, or a physical FIDO2 hardware key kept in a known, controlled place. For shared service laptops, a hardware key is often the cleanest option.
Administrators should also confirm the passkey (FIDO2) method is enabled in the tenant and, for accounts with access to sensitive data, require phishing-resistant authentication outright. Think of it as torquing every fastener to spec rather than leaving a few hand-tight.
Know the rollout timeline
Two dates drive the schedule. On September 1, 2026, passkeys become the default and accounts still on SMS or voice are auto-enrolled and prompted to register one. On February 1, 2027, Microsoft-provided SMS and voice codes are retired entirely. One caveat worth logging: this affects Microsoft’s own telecom delivery. If an organization has wired in its own external SMS/voice provider, that path is unaffected — but the free built-in codes most shops and practices lean on are going away.
Prevention: fold account hardening into your maintenance rhythm
The same discipline that keeps equipment reliable keeps accounts reliable. Add these to your preventive-maintenance thinking:
- Inventory the logins that reach patient data or equipment portals, the way you would inventory serviceable parts.
- Enroll passkeys everywhere they are offered, with a documented backup method per account.
- Retire SMS fallback for any account that has a working passkey, so the 2027 cutoff is a non-event.
- Verify recovery paths before you need them — a lost device should mean reaching for the backup key, not a support ticket.
Done on your schedule, this is a ten-minute upgrade per person that closes the most common way service accounts get compromised. Left undone, it becomes an emergency the first time someone types a code into the wrong page. Passkeys are the better part for the job — install them before the old one is pulled from the shelf, and log it as done.
Sources & further reading: