Two-step sign-in on every mailbox: turning it on, and proving it

No Irish or EU law in force names two-step sign-in as a duty for an ordinary small business. The rule is Article 32 of the GDPR: security appropriate to the risk, taking into account what current technology offers (the state of the art), the cost of implementation and the processing involved. Article 5(2) adds that the business in charge of the data (the controller) must be able to show it complies, which is why this guide ends on evidence.

NIS2 does name it. Article 21(2)(j) lists multi-factor authentication (MFA, the formal name for two-step sign-in), where appropriate, among the minimum measures. Under Article 2 it covers medium-sized and larger organisations in the sectors of its Annexes I and II, and a few types whatever their size, such as telecoms, trust service and DNS providers. A small firm outside those is not covered. Ireland has not yet made it Irish law (transposed it). On 8 July 2026 the European Commission referred Ireland to the Court of Justice for failing to notify transposition, and NIS2 in Ireland follows the case. A customer's questionnaire can still ask about it, as the NIS2 supplier questions explains.

The Data Protection Commission's own view is in its 2025 annual report, in the section on breaches notified by telecoms providers. Over one-third were phishing, including SMS phishing in which attackers obtained customers' passwords or one-time passcodes to get into their online portal accounts. The DPC considers multi-factor authentication 'a baseline security standard when it comes to providing access to online accounts'. It wrote that about telecoms customers' accounts: it is the regulator's view of the baseline, not a rule written for small businesses.

The National Cyber Security Centre's guidance on business email compromise, of 25 July 2025, is plainer: enforce multi-factor authentication on all email accounts.

The DPC's decisions turn that view into findings. In each of the four inquiries below, outsiders got into staff mailboxes, and the decision treated the lack of two-step sign-in as a failing in the organisation's security. Two of the DPC's orders named it. Three are public bodies; Virtue Integrated Elder Care operates five nursing homes. The last column is the decision's total fine, which for all but VIEC includes a fine for notifying a breach late.

For the admin portals, partly. For mailboxes, only where security defaults or a policy of your own covers them.

Microsoft's mandatory MFA covers sign-in to its admin portals: the Azure portal and the Microsoft Entra and Intune admin centers from October 2024, and the Microsoft 365 admin center, where enforcement began gradually in February 2025. Outlook and the mailbox are not on its list. Google says it will require 2-Step Verification on all administrator accounts, rolled out gradually over the coming years. Read on 16 October 2026, its page said enforcement had begun for Education, Nonprofits, Cloud Identity, Android Enterprise, and Enterprise editions that sign in through another provider. Business Starter, Standard and Plus are not on that list, so on those editions an admin's second step is still yours to enforce.

Microsoft rolls out security defaults, its free basic protection, to new Microsoft 365 accounts (tenants). It says a tenant created on or after 22 October 2019 might already have it. It also switches it on for existing tenants with no Conditional Access policies, no premium licences and no legacy authentication clients in active use, after notifying them. You can see whether yours has it on one screen in the Microsoft Entra admin center: Entra ID > Overview > Properties > Manage security defaults.

Microsoft describes three routes, and an organisation uses one of them. Security defaults and Conditional Access do not run side by side. Microsoft says a business that moves to Conditional Access must turn security defaults off.

Blocking older sign-in methods (legacy authentication) has a cost to plan for. Microsoft names SMTP among the protocols blocked, so a scanner, printer or business application that signs in with a username and password to send mail will be refused. Microsoft's security defaults page points to its guide on setting up a multifunction device or application to send email through Microsoft 365.

That change is coming anyway. The Exchange team says SMTP AUTH with a username and password will be off by default for existing tenants from the end of December 2026, though admins can turn it back on, and that it will announce a final removal date in the second half of 2027.

Security defaults also block device code sign-in (device code flow). It is a way to sign in on a device without a keyboard or browser, where the user finishes on another device. Microsoft says attackers abuse it in phishing, and that devices and apps which depend on it cannot sign in while security defaults are on. New tenants block it from 1 July 2026.

The setting is in the Google Admin console at Security > Authentication > 2-step verification, and only a super administrator can change it. Ticking 'Allow users to turn on 2-Step Verification' with Enforcement left Off lets users choose and requires nothing. Enforcement has two options: On, which starts immediately, or On from a date, which Google says starts within 24 to 48 hours of the date chosen.

Two settings on the same page leave gaps. A New user enrollment period, from 1 day to 6 months, lets new staff sign in with a password alone until it ends. The 'Allow user to trust the device' setting stops the prompt on that device. Google does not recommend it unless users frequently move between devices.

The methods setting decides how strong the second step is: any method; any except codes by text message or phone call; or only a security key, which now accepts passkeys too. Google says passkeys and security keys have the same level of phishing protection.

The second step goes to one person's phone or key. An account whose password several people share either has no second step, or depends on whoever holds the phone. Both platforms let each person reach a shared inbox through their own account.

In Microsoft 365 that is the shared mailbox. Microsoft says it is not intended for direct sign-in, its password is system-generated and not meant to be known, and you should 'always block sign-in for the shared mailbox account and keep it blocked'. People open it through their own licensed mailboxes, so their own sign-in and its second step protect it. A licensed info@ account whose password is passed around can be converted to a shared mailbox.

In Google Workspace it is delegation, which an admin turns on at Apps > Google Workspace > Gmail > User settings > Mail delegation. A delegate can read, send and delete mail in the account, cannot change its password or open its Google Account settings, and signs in as themselves. The info@ account then has one password, held by one person, and is enforced like any other account.

A break-in to a mailbox is a personal data breach. Assess it against the 72-hour reporting deadline, which the first 72 hours sets out.

Look in the right place. On 17 February 2020 the Teaching Council's IT staff received an alert headed 'Creation of forwarding/redirect rule'. They changed the user's password, checked the global forwarding rules in the Exchange admin portal and treated it as a false alert. The rule was on the user's own Outlook client, and it was found there on 6 March 2020, the first time the rules on that side were checked.

Not every rule forwards. At the University of Limerick, rules filed mail containing chosen keywords into a folder, and at Maynooth they hid messages from certain senders. Microsoft lists both kinds as warning signs: rules that forward mail to unknown addresses, and rules that move messages to the Notes, Junk Email or RSS Subscriptions folders. Blocking automatic forwarding to outside addresses deals with the first kind and not the second. Look at the rules themselves.

Microsoft's steps for a compromised mailbox, in its order:

In Microsoft 365, automatic forwarding to outside addresses is set in the outbound spam filter policy. Its default, 'Automatic - System-controlled', behaves differently in different organisations, so Microsoft says to choose On or Off. Off stops automatic forwarding to outside addresses, whether by inbox rule or mailbox setting, and sends a bounce message (non-delivery report) to the sender. The Auto forwarded messages report lists who is forwarding.

In Google Workspace, automatic forwarding is on by default. It is at Apps > Google Workspace > Gmail > End User Access > Automatic forwarding, where it can be turned off or limited to internal addresses. Google's checklist for a compromised account: suspend it, which resets its sign-in cookies and OAuth tokens; review its sign-ins in User log events, which go back up to six months; reset the password, revoke its OAuth tokens and remove its app passwords; and check its filters and forwarding with the user.

Export logs early. Microsoft Entra keeps sign-in logs for seven days on the free tier and 30 days with P1 or P2. A new or changed inbox rule is recorded elsewhere. Mailbox auditing logs it by default, and Microsoft Purview Audit (Standard) keeps audit records for 180 days. Purview keeps them longer only with Audit (Premium). Virtue Integrated Elder Care could not find the original phishing email: it had no email journaling, and a Message Trace review of the previous 90 days did not locate it.

A code or a prompt can be phished along with a password. The DPC's telecoms passage above describes SMS phishing that obtained passwords or one-time passcodes. A DPC case study describes an employee at a broadcasting organisation who received a phishing email posing as an internal vacancy. The employee supplied the email and storage sign-in details (credentials) and the MFA authenticator prompt it asked for. The attacker got into the account.

A stolen session skips the sign-in altogether. Microsoft describes adversary-in-the-middle phishing, in which an attacker placed between the two sides of a sign-in captures credentials and session cookies, 'even bypassing security measures like multifactor authentication'. Google calls it cookie theft, or session hijacking, and ends sessions where it detects a suspicious cookie. Both vendors' compromise steps above end existing sessions.

Consent phishing asks for permission, not a password. Microsoft describes it as tricking users into granting permissions to a malicious cloud application, which can then reach their data. It recommends letting users consent only to apps that meet criteria you set, such as verified publishers and low-risk permissions. Google's Security report counts the outside apps each user has authorised, and each user's security page lists them so you can remove their access.

For a second step built to resist phishing, Microsoft's Conditional Access has a phishing-resistant MFA strength, and Google points to security keys and passkeys. Under security defaults, the user types a number shown on the sign-in screen into Microsoft Authenticator, which Microsoft says helps stop users falling for MFA fatigue attacks (a stream of sign-in prompts sent in the hope the user approves one).

OBF Insurance Group, an Irish broker, says many underwriters will expect to see proof of the controls they ask about, MFA across email, remote access and admin accounts among them. It says leaving MFA off where a cloud service offers it could trigger an automatic failure, and tells applicants to 'collect screenshots, reports, and evidence of configuration'. What a cyber insurance proposal form asks goes through the questions. One dated set of exports answers the insurer, the customer and an inquiry alike:

The evidence is true on the day it was exported, and a new starter, shared mailbox or admin changes it. Article 32(1)(d) of the GDPR asks for a process for regularly testing, assessing and evaluating the effectiveness of security measures. A repeated, dated export is a simple one.

The NCSC's business email compromise guidance lists several controls against payment fraud. One is two-step sign-in. Another is checking any change to payment details by phone, using contacts you already know, which invoice redirection fraud covers. A third is the email security records on your domains (SPF, DKIM and DMARC), which the DMARC guide covers.