Map privileged sign-ins
A small company may have only a few people who can change billing, domain records, cloud storage permissions and the online shop. That makes each administrator login unusually consequential. Start with a list of systems and the actual accounts that can change settings, export records, invite users or disable security controls. Include vendor dashboards and emergency accounts, not only the company email system. Record the account owner, current sign-in method, device dependency and who can revoke access. This inventory is a practical rollout map: it shows which accounts need protection first and where a single lost phone could halt operations. Do not treat a shared administrator password as an acceptable way to avoid individual enrolment; separate named access makes an unexpected sign-in attributable.
Rank by what an account can do rather than its job title. A bookkeeper with access to payment details, a contractor able to deploy the website and an owner able to reset everyone else’s credentials may all deserve early attention. Note whether the platform supports a security key or passkey, an authenticator app, or only an older method. Ask the provider what sign-in and recovery options the purchased plan actually permits before announcing a universal policy. A policy that asks staff to use a method unsupported by one critical service will create an informal exception. Keep that exception visible, with an owner and a target for replacement, instead of quietly describing the whole estate as protected.
Choose a defensible method
Multifactor authentication adds evidence beyond a password, but methods differ. NIST explains that codes typed into a page, including one-time passwords, are not phishing-resistant: a fraudulent site can relay a code to the real service. WebAuthn and FIDO2 methods bind the response to the verifier name and can resist that attack when implemented correctly. A security key or suitable passkey is therefore a strong preference for accounts that can change organisation-wide settings. This is a risk-based recommendation, not a claim that every service offers the same options. Where a stronger method is unavailable, turn on the best supported MFA and keep the gap in the risk register.
Avoid the misleading shorthand that a passkey always means two factors. NIST distinguishes a cryptographic authenticator used with user verification from one used without it. Check the platform’s policy and the device experience: does the user have to unlock the authenticator, and can another person holding an unlocked device sign in? Also decide who owns the key or device, whether it may be synchronised, and how a departing worker’s access is removed. These operational questions matter as much as the label on the sign-in button. Demonstrate the chosen method on the systems staff actually use, including remote work, before withdrawing an older method.
Enrol without a lockout
A safe rollout has a preparation stage and a change window. Give each administrator a named account, confirm contact details, and enrol the first authenticator while they still have a working sign-in. Where supported, register a second appropriate authenticator under the same person or a documented alternate path. Test a fresh browser session rather than relying on a device already signed in. Then require the method for a small pilot group, check sign-in logs and help requests, and expand by role. Microsoft’s Entra registration campaign documentation illustrates one product-specific way to target users and prompt registration after MFA; it is a useful example, not an instruction that every SME must buy or configure Entra.
Suppose a retailer has an owner, a stock manager and an external web developer. The owner can alter payment settings; the manager can export orders; the developer can deploy code but should not view payment information. Give the three people only the roles they need and pilot MFA on the owner’s privileged account first. Ask each person to sign in on a second browser and record a successful test. If the developer’s platform lacks the preferred factor, document that limitation and restrict the role rather than granting a shared owner login. This scenario is a planning illustration, not a measured customer result. Its value is to expose different privileges and the failure path before a forced company-wide switch.
Plan lost-device recovery
Recovery is part of the design, not a reason to keep MFA switched off. Decide what happens if a phone is lost during a busy trading day, a security key breaks, or the only administrator leaves. NIST describes backup and alternate authenticators and recovery codes, while also making clear that look-up secrets are not phishing-resistant. Keep recovery material in controlled storage, limit who can use it, and make every use visible to another authorised owner. A help-desk reset based solely on an email or chat message can become the weak entry point. Require a documented identity check and log the person who approved and executed a reset.
Test recovery with a non-production or low-risk account before a real incident. Write the exact service-specific steps: who receives the request, how the requester’s identity is checked using a trusted channel, who can approve a new authenticator, what old sessions or devices are revoked, and how access is restored. If the service provides emergency accounts, protect and monitor them according to its own guidance; do not use one for daily work. After a recovery, review sign-in events and remove any temporary exception. Rehearsal should prove that the business can continue without handing an unverified caller an administrator session.
Measure completion by usable access
An enrolment count alone does not prove the policy works. For each privileged role, check that the required method actually appears at sign-in, the user can complete a fresh login, older bypass routes are closed or documented, and access is limited to the intended tasks. Test both ordinary work and one controlled recovery. Note the date, system, role, tester, result and corrective action. Revisit accounts after staff or supplier changes and when a platform adds a stronger method. This makes the rollout an operational control rather than a one-time announcement. It also avoids claiming that a successful test on one service automatically protects the others.
A practical next step is to choose the one account that could cause the widest damage, verify its supported authenticators and recovery route, and pilot there with its real owner. If the method fails or locks out that person, fix the enrolment or recovery process before expanding. Keep the decision record short: the chosen method, why it fits the role, the unsupported services, the backup route and the next review date. The purpose is to make a future administrator able to repeat and audit the decision. Astera can help map privileged workflows and implement sign-in changes, but the business owner should approve who receives each powerful role.
Watch for bypass and unusual prompts
Once MFA is enabled, monitor the events that reveal whether people are using it as intended. Repeated unexpected push prompts, a sudden registration of a new authenticator, frequent fallback to a weaker method, and an emergency account sign-in all deserve investigation. NIST recommends limiting the rate or total number of out-of-band push notifications since the last successful authentication. Tell staff to report prompts they did not initiate through a known internal channel, and give the administrator a clear way to revoke sessions and inspect recent changes. Do not teach users to approve a prompt merely to make it disappear. Record the investigation outcome so recurring friction can be separated from a possible attack.
A quarterly review can compare the privilege inventory with current people and real tasks. Remove obsolete contractor access, check that new administrators enrolled an appropriate factor, and retest an emergency path after changing identity providers or devices. Review failed sign-ins as context, not as a simplistic score of security: a user mistyping once is different from repeated attempts on an unused account. The business should decide who receives alerts outside office hours and how an incident is escalated. The review is complete only when someone can show which accounts remain exceptions and who accepted the resulting operational risk.
Before expanding MFA
- List every privileged account and its real owner.
- Test a fresh sign-in and one controlled recovery for each critical platform.
- Record weaker methods and exceptions with an owner and review date.
