Passkeys for Microsoft 365: Move beyond SMS without locking your SME out

Management asks whether Microsoft 365 is secure. The answer is: “We have MFA everywhere.” That sounds reassuring, but it does not explain how people actually sign in. A password with an SMS code, approval on a phone and a passkey are different methods. For an SME, the important question is not how many security switches are enabled. It is whether access works reliably while making common attacks harder.

My recommendation is specific: review the sign-in paths used by administrators and particularly exposed employees first. Then run a small passkey pilot. Do not disable SMS for everyone overnight or buy a security key for every employee before understanding the requirements. The right sequence is to understand the baseline, test recovery, trial the new method and enforce the intended protection.

This article uses primary sources from Microsoft and the FIDO Alliance checked on 23 September 2026. Product capabilities are vendor statements. The selection matrix, budget and rollout plan are my recommendations, not mandatory standards or claimed customer results. The topic is timely because the documented choices now extend beyond a single type of passkey.

The FIDO Alliance describes passkeys as credentials based on cryptographic key pairs. Instead of transmitting a reusable password, the device proves possession of the appropriate key. Binding authentication to the correct service makes the method phishing-resistant. Depending on the device, a PIN or biometrics authorises its use. Passkeys can be device-bound or synchronised through a provider.

This does not mean complete security. A compromised endpoint, excessive permissions and a fraudulent support request remain separate problems. Strong authentication does not replace updates or sensible access management. Treat the passkey as a better front door, not as the security design for the entire building.

Employees need a straightforward explanation: “You confirm sign-in with your approved device or key. If it is unavailable, there is a tested recovery process.” They do not need to understand cryptography. They need to recognise the expected dialogue, question unexpected requests and know whom to contact when something goes wrong.

Microsoft distinguishes between MFA, passwordless MFA and phishing-resistant MFA in its authentication strengths. Authenticator phone sign-in, for example, is not automatically phishing-resistant; Windows Hello for Business and FIDO2 security keys are among the designated methods. Conditional Access can require an appropriate strength for selected access and needs Microsoft Entra ID P1.

The practical implication for your IT provider is simple: do not write only “enable MFA” in the assignment. Ask for a clear account of which identities may use which methods for which applications. Registering a strong method achieves little if a weaker alternative still satisfies the same protected access requirement.

Do not confuse unlocking a device with accessing every business application. Test the complete working journey: open the laptop, launch the browser, use Teams and enter a specialist application. The objective is a dependable workplace, not one successful screenshot from the administration portal.

The FIDO enterprise deployment guidance deliberately distinguishes device-bound from synchronised passkeys. Assurance requirements and portability are important selection criteria. My practical conclusion is to segment by working pattern and risk instead of imposing one solution on every employee.

This table provides an initial direction, not a compatibility guarantee. Check browsers, operating systems, remote desktop scenarios and older applications in particular. “It works for IT” is not an acceptance criterion for reception or production staff. One untested specialist workstation can unnecessarily delay an otherwise sound rollout.

Provide an equivalent option for people who do not use a personal smartphone for work. Access should not silently depend on every employee supplying a private device. Also decide who replaces a lost key and how quickly a replacement can reach each location. Physical logistics belong in the design, not in an incident-time improvisation.

The current Microsoft setup documentation covers device-bound and synchronised passkeys and group-based passkey profiles. The passkey method itself is available in Entra ID Free. This is separate from licensing the intended access enforcement. Note that enabling passkey profiles cannot be undone according to the documentation. Restricting approved keys can block existing sign-ins.

Start with a documented assessment rather than an impromptu production change. Which policies already apply? Which groups overlap? Who has SMS as their only second method? Who has registered an alternative but never uses it? Distinguishing these cases prevents an apparently complete registration report from creating false confidence.

For the pilot, I recommend a clearly named group containing a few people from different business functions. Record the previous configuration and decide who may reverse a change. Not every product option is reversible. A fallback plan must therefore address the specific intervention rather than simply promising to “put everything back”.

Microsoft's Temporary Access Pass is a time-limited code that can help with registering new authentication methods and recovering access. It can be configured for one-time or repeated use. This is a tool for a controlled process, not permission to skip identity checks.

My recommendation is to have support rehearse a complete device-loss scenario with a test account. The person must not use their previous phone or security key. Support verifies identity through a previously agreed independent route, enables new registration and records the intervention. An email sent from the affected account should not be sufficient evidence on its own.

If theft is suspected, the process must also address existing sessions and lost credentials. Define who makes those decisions. Restoring access quickly is not necessarily the same as restoring it safely. Measure both the time required and whether the control steps were followed correctly.

Include holidays, field work and out-of-hours situations. If the only responsible administrator is on a flight, an otherwise tidy process may be unusable. At least one deputy must actually be able to execute it, rather than merely appearing as a name in the documentation.

Microsoft recommends at least two cloud-only emergency accounts with strong authentication that remains independently available where possible. Its guidance recommends FIDO2 passkeys. Blocking access policies must not defeat the emergency route, and the accounts should be monitored and regularly validated.

For a small company, my operational addition is to identify who authorises emergency use, who acts and where instructions remain accessible outside a potentially locked workplace. Do not store the spare authentication equipment together with the only production device. Record a test in which normal administrator access is deliberately not used.

An emergency account is not a convenient second account for daily tasks. Every use needs a documented reason and a subsequent review. These operating rules make the difference between a necessary exception and a permanent security gap. Keep them concise enough that another responsible person can understand them under pressure.

The following is my illustrative planning calculation in CHF, not a market price or quotation. It assumes ten pilot participants, four physical keys including spares, and an internal fully loaded cost of CHF 100 per hour. Existing devices are reused. Your current agreement determines whether additional licences are required.

An assumed extra 20 minutes of support per participant would add approximately CHF 333. This makes the source of budget uncertainty visible. Obtain current quotations before purchasing: CHF 60 is explicitly a calculation input here, not a verified price for any particular product.

Do not manufacture a spectacular return by assigning a convenient value to hypothetical prevented attacks. Observable pilot outcomes are sufficient: registration time, failed sign-ins, support effort and a successful recovery test. Those results provide a defensible basis for deciding how to expand.

Keep one-off implementation work separate from recurring operations in the final decision. Someone must maintain instructions, review exceptions and support replacement devices after the project closes. A low initial hardware bill is not evidence of low lifetime effort. Equally, a difficult first setup session does not automatically mean the approach is unsuitable.

Week one: Inventory accounts, sign-in methods, critical applications and specialist workplaces. Appoint an owner and a deputy. Management confirms which roles should receive protection first and how much disruption the pilot may cause. The resulting scope should be specific enough for support to recognise whether an incident belongs to the pilot.

Week two: Prepare emergency access and recovery. Test both before enforcing new requirements. Then select pilot participants and suitable methods. Write a short guide using the actual dialogues from your environment instead of producing a lengthy generic training presentation. Include a clear contact route for people who cannot sign in.

Week three: Assist registration and test the relevant working journeys. Assess proposed access rules in a controlled way, for example using report-only mode where available. Observation does not block access and therefore does not yet enforce protection. Move to targeted enforcement only after reviewing the evidence and approving the change.

Week four: Rehearse device loss, review logs and obtain confirmation from business teams that work remains practical. Then decide on the next group. Give each transitional exception an owner and an expiry date. Replace SMS where the alternative and recovery route have demonstrably worked, rather than treating a calendar date as proof of readiness.

Acceptance should answer three questions. Can every pilot participant do their work? Does protected access actually require the intended method? Can support recover access safely after a loss? If any answer remains open, fix that specific gap instead of simply increasing the number of participants.

Keep the evidence lightweight: a short test record, the affected account group, observed issues and the decision owner are more useful than a large project report nobody maintains. Agree how new starters and role changes enter the same process. Otherwise, the environment can gradually drift away from the state that passed the pilot.

Passkeys are a sensible next step for Microsoft 365 environments. Their value comes from aligning devices, policies and support, not from enabling a tenant-wide switch. For Swiss SMEs, a small pilot with clear acceptance is usually a better first investment than a broad rollout with unresolved exceptions.

Start with one question for your IT provider: “Which important accounts can still access resources using a weaker method, and how do we test a stronger alternative together with device-loss recovery?” The answer should produce a concrete assignment rather than another general security promise.