Passkeys let people sign in using public-key cryptography and a local device unlock, without a password. If your business uses Microsoft Entra ID, review who still authenticates by SMS or phone call: Microsoft has begun a transition with specific dates. Its scope differs across accounts, environments and services, so check the applicable policy before making changes.
What is a passkey, and why might a small business care?
Imagine, as a hypothetical example, an advisory firm whose employees use invoicing software, email and shared documents. Every change of phone triggers a support call to recover access. Sometimes a code arrives late; sometimes someone cannot distinguish a legitimate message from impersonation. The operational problem is depending on a fragile route into the tools needed every working morning.
A passkey uses a pair of cryptographic keys. The service holds a public key; the private key remains protected in the compatible device or manager. A person uses a local method, such as a PIN or biometrics, to unlock it. Google's passkey documentation explains that biometrics are not sent to the website as part of this process.
The main security advantage is phishing resistance: the credential is linked to the domain or application for which it was created. A fake page should not obtain a valid authentication for the genuine service. That does not make an account invulnerable. Compromised devices, configuration errors, open sessions and poorly designed account recovery still create risks that need attention.
Distinguish three terms. A password is a secret the user knows. An SMS code is a verification method delivered through telecommunications. A passkey is a cryptographic credential. Some passkeys synchronise through a manager; others are bound to a device or physical FIDO2 key. The appropriate choice depends on the account's sensitivity and the organisation's policies, rather than a universal preference for one device.
What changes in Microsoft Entra between 2026 and 2027?
The current trigger is specific. In its official FAQ, updated on 23 September 2026, Microsoft explains that from 1 September 2026 it enables passkeys for certain users with SMS or voice configured. The transition is phased. Review the authentication policy applying to your environment instead of assuming that the same setting covers every account.
The documentation gives 1 February 2027 as the retirement date for Microsoft-provided SMS and voice methods for many affected users. It gives 1 July 2027 for global administrators and certain external users. There are distinctions for internal guests, cloud environments and telephony-provider options. Do not turn those dates into a universal rule for every Microsoft account or every business using its products.
Microsoft also explains that not everyone simply loses access automatically. In certain cases, someone with only SMS or voice must register a passkey before continuing. That can interrupt work if devices, support and recovery are unprepared. Check the current documentation and its scenarios before executing changes; an operational plan needs to reflect the users actually affected.
An integration can also depend on who granted an authorisation and how it is renewed. Review those links with the technical owner before changing access methods. A user account and an application identity are not interchangeable. For a small business, the useful question is which access depends on one particular person and what happens if they cannot authenticate tomorrow.
How do you identify business access that needs attention?
Do not start by buying physical keys for everyone. Start with an inventory covering email, domain administration, advertising, the online shop, CRM, document management, invoicing, no-code tools and technical accounts used by integrations. Identify the owner, access method and recovery procedure for each. The list should explain responsibilities without becoming a second store of credentials or secrets.
| Access | What to check | Risk signal |
|---|---|---|
| Administration | Who holds elevated privileges | Only one person can recover the account |
| Email and documents | MFA method and registered devices | An SMS goes to an old phone |
| Advertising and integrations | Authorisations and OAuth tokens | Nobody knows who granted permission |
| Business software | Passkey compatibility | The application only supports passwords |
| Shared accounts | Ownership and auditability | Several people use the same login |
Check the difference between user authentication and application authentication. An automated process using OAuth or a service identity is managed differently from an employee's sign-in. Replacing a token with a password stored in a workflow without analysis could weaken security and make renewal harder. Knowing that something connects successfully is not enough to understand its maintenance requirements.
Microsoft provides specific guidance for enabling and managing Entra passkeys. Use it to confirm device requirements, policies and restrictions in your environment. Do not assume every function is available for every profile or version. That compatibility check belongs before a rollout, when the team can still plan around a limitation rather than discover it during an incident.
What happens if someone loses their phone or security key?
Once people understand that the private key is not held by the website, a reasonable question follows: does losing a phone mean losing access to work? It depends on whether the passkey synchronises through a compatible manager, is bound to a particular device, or sits on a physical key. Recovery must be designed before an incident, not improvised while the business waits.
Define at least two authorised recovery routes for critical accounts, subject to the provider's policies. Another previously registered authenticator, support with identity verification or managed recovery may be involved. These options are not available in every service. Enabling a weak alternative can also undermine part of the security improvement, so continuity and protection need to be considered together.
Imagine a shop manager losing her phone while travelling. If advertising access depends on that one device, the campaign may keep running while the team cannot handle an incident. The transition should preserve business continuity and control, rather than move every dependency onto a newer device. This is a hypothetical situation illustrating the recovery question, not a client outcome.
Document offboarding too. When someone leaves, revoke sessions, credentials and permissions through the relevant system. Moving to passkeys does not replace a joiner and leaver policy. Authentication protects entry; authorisation determines what someone can do after entering. A successful sign-in therefore does not prove that the account has the right privileges or that old access has been removed.
How can you introduce passkeys without blocking work?
Propose a small, representative pilot: someone in administration, someone working away from the office and someone using critical tools. Check registration, normal sign-in, changing devices and recovery. The first successful login is only part of the test. The difficult case is the day something goes wrong and the team needs a documented way to continue.
Before rollout, explain what changes and what stays the same. A passkey may unlock through a fingerprint, face recognition or local PIN; this does not imply that the employer receives a copy of the fingerprint. Explain where to ask for help and what information should never be shared, particularly when unexpected messages request codes or approvals. Clear instructions are part of the process.
During migration, record exceptions: supplier accounts, older terminals, shared equipment, guests and automated connections. Each needs an owner and a decision: adapt, replace, retain temporarily with controls or review with the vendor. One policy does not resolve every environment. An exception left without a decision can become an undocumented dependency that nobody remembers to revisit later.
After the change, review failed access and recovery requests. If they multiply, an unclear instruction or missed incompatibility may be responsible. Adjust the process without relaxing controls indiscriminately. The aim is safer access that remains usable, rather than a technical demonstration that works only under ideal conditions. Feedback from ordinary working situations helps reveal whether the planned recovery routes are understood.
How do we approach this at meiika?
At meiika, we design custom systems with attention to who accesses them, which permissions they need and how service continues when the team changes. Access affects the continuity of integrations; it is not simply a final configuration detail. A connected process needs both an operational owner and a clear understanding of its dependencies.
We also consider limits for self-management agents. An agent should not inherit personal credentials without control or operate with unnecessarily broad permissions. We do not claim a particular configuration is secure without examining the actual environment. A proposed design and a verified implementation remain different things, and a first discussion does not require sending account secrets.