Stronger website sign-ins with passwords, passkeys and MFA

A website administrator’s account can change content, install code or reach customer records. The email address used for password recovery can be just as powerful. Protecting these accounts is therefore a business responsibility, not simply a matter of choosing a memorable password when the website is first created.

Start with an account inventory covering the domain registrar, DNS provider, hosting panel, email, CMS, payment services and any code repository. Identify the owner and recovery route for each. Prioritise accounts whose loss would stop trading or let an attacker take control of other services. The NCSC’s current guidance recommends passkeys for important accounts where available, with strong unique passwords and two-step verification where passwords remain in use.

Use a different password for every important service

Reusing a password means a breach elsewhere can become a website incident. A hosting account, staff email and a personal shopping account should not share a credential. Choose a long password or passphrase that is difficult to guess, and avoid company names, addresses, seasons and predictable variations. A short password with familiar substitutions is not made strong simply by adding an exclamation mark.

Where staff need to create memorable passwords, the NCSC’s approach of combining unrelated words can be useful, but uniqueness remains essential. Do not publish a pattern everyone follows. Change passwords that have been exposed, reused or shared inappropriately, and follow the service’s response process when compromise is suspected. Routine changes are not a substitute for making the existing credential strong and protecting how it is recovered.

Use a password manager as an operational tool

A suitable password manager can generate unique passwords and help staff use them on the correct sites. Choose a business arrangement that supports the team’s access and recovery needs. Plan what happens when the owner is unavailable, a device is lost or a member of staff leaves. Protect the password manager itself with strong authentication and store recovery material securely.

Shared business access should be deliberate. Use the manager’s supported sharing controls where appropriate rather than sending passwords in chat or storing them in a general spreadsheet. Give staff individual CMS accounts whenever the application supports them. This makes it easier to remove access without disrupting everyone else and provides a clearer record of who performed an administrative action.

Understand what multi-factor authentication adds

A second factor provides a different form of evidence beyond the password. Common implementations include an authenticator app, a security key or a code delivered through another channel. Two-step verification and MFA are often used together in product interfaces, but the practical question is which protections the implementation provides and how recovery works.

Enable the strongest supported option that the organisation can manage reliably. SMS-based verification is generally preferable to having no additional protection when that is the available choice, but it has different risks from a phishing-resistant security key or passkey. Do not turn off verification for the most privileged account simply because it is used less often. Test the process with the devices and accessibility requirements of the people who need it.

Consider passkeys for business-critical accounts

Passkeys use a public-key authentication approach and are designed to resist common phishing attacks that trick people into entering a password on the wrong website. The device or credential provider normally protects use of the passkey through an unlock method such as a PIN or biometric check. Availability and management differ between services, so check the provider’s current instructions.

Review whether passkeys are synchronised through a personal or business account, how a replacement device is authorised and whether more than one recovery route is available. Adding a passkey does not automatically remove an existing password or its recovery vulnerabilities. Protect any remaining sign-in methods too. For a small business, the most secure choice must also be recoverable without relying on a single person’s private phone.

Secure the recovery process

Attackers may target recovery rather than the normal login screen. Keep the recovery email protected, remove former employees’ addresses and review old phone numbers. Store backup codes somewhere secure and separate from the device used for everyday authentication. Avoid leaving a screenshot of those codes in an unprotected photo library or shared folder.

Define how the business will verify a request to reset an important account. A message that appears to come from a director is not enough by itself. For especially sensitive changes, use a trusted independent channel and the service’s documented recovery procedure. Never give a support agent a one-time authentication code unless the service’s official workflow explicitly requires that exact action and you have verified the destination.

Reduce the value of a stolen account

Give users the permissions needed for their job. A content editor should not automatically be able to change payment settings or install executable extensions. Remove unused accounts and review temporary developer access at the end of a project. API keys and automated service accounts need the same attention as human logins, including scope, rotation after exposure and revocation when no longer needed.

Separate production and test access where practical. Do not copy a full set of live credentials into a demonstration site. If the application supports approval or audit records for important actions, use them to make changes reviewable. Authentication establishes who is signing in; authorisation still determines which actions that person is allowed to perform.

Protect the login and session around authentication

Use properly configured HTTPS and keep the application supported. Rate-limit abusive sign-in attempts without creating an easy way to lock out legitimate users. Avoid error messages that disclose more account information than necessary. Developers should use the platform’s supported password hashing and session controls rather than inventing their own authentication system.

Sessions should have appropriate expiry, logout and revocation behaviour for the application’s risk. An existing session should not silently retain privileged access after an account is disabled or its security state changes. Sensitive actions may warrant re-authentication. Test these cases alongside normal sign-in, especially after introducing a proxy, changing the public domain or adding another customer-facing application.

Recognise phishing before it becomes a login event

Train staff to reach important services through known addresses or bookmarks. Check unexpected password-reset notices and requests for urgent verification through a trusted route. A professional logo and an HTTPS connection do not prove that a page belongs to the expected supplier. Password managers and passkeys can help, but staff still need a clear reporting process for messages that seem wrong.

Do not blame people for reporting a mistake. Prompt reporting can allow the team to revoke sessions, change affected credentials and investigate before an attacker makes further changes. Keep incident contacts available outside the website itself, particularly if email or the hosting account is the service affected.

Test the complete account lifecycle

Verify enrolment, everyday sign-in, a lost-device scenario, recovery, staff removal and logout. Confirm that changing a password or disabling an account has the intended effect on existing sessions and connected applications. Record the result without storing secret values in the test notes. Repeat the check when authentication tools or staff responsibilities change.

For a UK business website, this combination is stronger than a password rule alone: unique credentials, supported stronger authentication, sensible permissions and a rehearsed recovery process. Apply it first to the accounts that can control domains, email, hosting and payments, then extend it to the rest of the organisation’s services.