Multi-factor sign-in and passkeys for your CMS, AWS, and hosting accounts

An editor at a county health department reuses the same password for the CMS and a shopping site. The shopping site is breached, the password list is sold, and two weeks later an automated tool tries that email and password on the county's CMS login page. It works. By the time anyone notices, a page about vaccine clinics links to a fraudulent payment site. Nothing was wrong with the server or the code. A second sign-in step would have stopped the attack at the login page.

Why passwords alone are not enough

Billions of email and password pairs from old breaches circulate freely, and attackers test them automatically against every login page they can find. Phishing emails that copy a real sign-in page add more every day. A password, however strong, can be reused, guessed, or handed over. Multi-factor sign-in (often called MFA or two-factor) adds a second proof that an attacker does not have: something on your phone or a physical key.

Not all second factors are equal

Government agencies will recognize the term "phishing-resistant." Federal guidance requires phishing-resistant methods for federal staff, and passkeys and security keys are what that means in practice. They are also simpler for users: no code to copy.

Which accounts to protect first

1. Cloud and hosting control panels. An AWS or Azure administrator account can delete everything, backups included. Protect the AWS root user with a hardware key and keep it in a safe place; daily work should never use it.
2. Domain registrar and DNS. Whoever controls DNS controls where your site and email go. This account is often forgotten and rarely has MFA.
3. CMS administrator accounts. Anyone who can install plugins, edit templates, or create users.
4. Email accounts of administrators. Password reset links land there.
5. Everyone else in the CMS. Editors and authors last, but not never.

Single sign-on makes this manageable

The easiest way to enforce MFA everywhere is to stop managing separate CMS passwords. With single sign-on (SSO), staff sign in through your organization's identity provider, such as Microsoft Entra ID, Okta, or Google, and the identity provider enforces MFA once for every connected system. When someone leaves, disabling one account removes their access everywhere. Most agencies and universities already have an identity provider; connecting the CMS to it is usually a small project.

Setting it up by platform

• WordPress: core does not include MFA. Add it through a maintained security or SSO plugin, and enforce it for administrator and editor roles rather than leaving it optional.
• Drupal: use the Two-factor Authentication (TFA) module or an SSO module (SAML or OpenID Connect), and require it by role. Government Drupal sites usually connect to the agency identity provider through SAML.
• Cascade: Cascade authors can sign in through your organization's SSO, which brings your MFA policy with it; see setting up single sign-on for Cascade authors.
• AWS: require MFA for every human user, use AWS IAM Identity Center for staff access rather than individual long-lived users, and lock away the root user.

Do not forget recovery

MFA fails badly when someone loses a phone the day before a deadline. Register two methods per person, such as a passkey on a laptop and an authenticator app on a phone. Keep printed recovery codes for break-glass administrator accounts in a secure location. Decide in advance who can reset a colleague's MFA, and require them to confirm the person's identity by a separate channel before they do.

How eWay handles access

On environments eWay manages, MFA is enforced for all administrative access. Server access goes through SSH keys or AWS Session Manager via a controlled path, with no inbound SSH from the internet, minimal standing privilege, and every privileged session logged. Under the shared responsibility model, your organization manages CMS user accounts and roles, and eWay can help connect your CMS to your identity provider so your MFA and offboarding policies apply automatically.

What to include in a support ticket

• Whether you are asking to set up MFA or SSO, or reporting a locked-out user
• The site and the CMS, plus your identity provider if you use one
• For a lockout: the username, and how you confirmed the request came from that person

eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: least-privilege access and offboarding and if your site is hacked: the first hour.