Multi-factor authentication for public servants, when the constraints are real

Most compromises of government accounts do not begin with sophisticated exploits. They begin with a password that was guessed, reused from another service, or typed into a convincing fake login page. Multi-factor authentication, which requires something beyond the password before access is granted, is the single control that most directly blunts these attacks. The question for a ministry is rarely whether to adopt it, but how to make it work for a workforce in which not everyone has a personal smartphone, connectivity is intermittent and terminals are often shared. NIST SP 800-63B is a useful reference for thinking about authenticator strength, because it distinguishes between factors that resist phishing and those that do not. In practice, public institutions choose between four families.

• Hardware security keys using FIDO2 or WebAuthn. These are the strongest common option and resist phishing, because the key will only respond to the genuine site. They need no network connection or phone, but they cost money, must be issued and tracked, and can be lost.
• Authenticator apps generating time-based codes or push approvals. These are inexpensive and work offline for codes, but require a smartphone. Push approvals can be abused by attackers who send repeated prompts until a tired user accepts, so number matching should be enabled where available.
• Platform authenticators and passkeys built into modern laptops and phones. Strong and convenient on personally assigned devices, less suitable for shared terminals.
• SMS or voice one-time codes. Better than a password alone, but the weakest option: codes can be intercepted through SIM swap fraud, redirected by compromised mobile accounts, or phished in real time, and delivery depends on network coverage.

Treat SMS as transitional and tier users by risk

SMS deserves particular caution because it often feels like the natural choice where mobile phones are universal and smartphones are not. It should be treated as a transitional factor, used where nothing else is yet practical, and never as the only factor for administrators, finance officers or anyone who can approve payments or change records. A single policy for everyone either leaves privileged users under-protected or imposes cost on staff who do not need it. Assign authenticators based on what an account can do.

• System administrators, identity administrators and anyone with access to payroll, treasury or procurement approvals: hardware security keys, with a registered backup key.
• Staff handling personal data or sensitive case files: authenticator app with number matching, or a hardware key where no suitable phone is available.
• General staff using email and collaboration tools: authenticator app as the default, with SMS permitted temporarily and on a documented exception list.
• Service and integration accounts: no interactive login at all; use managed credentials with restricted scope and regular rotation.

Shared terminals, field offices and recovery

Shared computers are common at service counters, clinics and district offices. The answer is not to exempt them but to tie the second factor to the person rather than the machine. Hardware keys work well here because each officer carries their own and the terminal needs only a USB or NFC reader. Sessions on shared machines should be short, lock on inactivity and never remember the device. Where connectivity is unreliable, prefer factors that work offline, such as hardware keys or app-generated codes, over push notifications and SMS that depend on the network at the moment of login. Every authenticator will eventually be lost, broken or left at home. If recovery is a phone call in which the caller states their name and asks for a reset, attackers will use that call. Recovery should require identity verification at least as strong as the factor being replaced.

The strength of multi-factor authentication is set by its recovery process, not by the factor printed on the brochure.

• Register a second authenticator for each user at enrolment wherever possible, so most losses never reach the help desk.
• For privileged users, require in-person recovery with photo identification, or confirmation by a named line manager through a separate channel.
• Issue short-lived temporary access codes for recovery rather than disabling multi-factor authentication on the account.
• Log every reset, alert the user through an existing channel, and review resets weekly for patterns.

Roll out in phases, with the help desk ready

Large-bang rollouts tend to provoke a flood of lockouts, a political backlash and a quiet rollback. A phased approach builds confidence and a support capability at the same time. Before each phase, publish plain-language guidance explaining why the change is being made, what staff need to bring to enrolment, and whom to contact if something goes wrong. Senior officials should enrol early and visibly; a permanent secretary who uses a security key every morning is the most persuasive argument the programme has.

• Phase one: IT and security staff, followed by all administrators. They are the highest-value targets and the best testers.
• Phase two: finance, human resources and procurement, where account compromise leads directly to fraud.
• Phase three: the remaining workforce, ministry by ministry, with an enrolment window, drop-in sessions and a fixed enforcement date.
• Throughout: block legacy authentication protocols that cannot perform multi-factor checks, or the control can simply be bypassed.

The help desk will carry the rollout. Give agents a written script for enrolment problems, lost devices and clock drift on code generators, and make sure they know which requests they must not fulfil over the phone. Staff the desk more heavily in the week after each enforcement date. Track the reasons for calls and feed them back into the enrolment guidance, so the same problem is not solved one call at a time.

Pitfalls to avoid

• Leaving exceptions open indefinitely; every exception should have an owner and an expiry date.
• Forgetting remote access, webmail and administrative consoles, which are exactly where attackers look.
• Allowing users to approve prompts they did not initiate without any warning or reporting route.
• Buying hardware keys without an inventory, issuance record and process for revoking lost keys.

Multi-factor authentication is not a product purchase; it is a change in how every public servant signs in, with a support process behind it. Planned around the real constraints of the workforce, it raises the cost of attack substantially without making the working day harder than it needs to be.