Implement Multi-Factor Authentication

Multi-factor authentication (MFA) requires users to provide two or more different forms of identification, such as a password and a dynamic code from a mobile app, to access an account. It is required for compliance because it drastically mitigates the risk of data breaches caused by compromised, guessed, or reused passwords.

CyberSecure Canada Section 5.5.2.1 requires that organizations implement multi-factor authentication across their systems, or formally document all instances where they cannot or make a business decision not to do so.

Organizations should prioritize implementing MFA on all remote access points (such as VPNs), cloud services like Microsoft 365 and Google Workspace, email platforms, and especially all privileged accounts and administrators.

The baseline controls emphasize securing remote access and cloud infrastructure, but the standard broadly expects MFA implementation across organizational systems. Any system without MFA, whether internal or external, should ideally be documented as an exception if it poses a risk.

Organizations must maintain an MFA exception register or risk register that outlines the specific system or account, the reason MFA cannot be applied, executive approval accepting the risk, and any compensating controls in place.

Acceptable business justifications typically involve legacy systems that technically cannot support modern authentication protocols, or automated service and API accounts where interactive MFA would break critical business integrations.

When MFA cannot be implemented, organizations should apply compensating controls such as strict network segmentation, IP address allowlisting, complex password requirements, and enhanced monitoring for anomalous login behavior.

Auditors will look for a documented access control policy, technical configuration screenshots showing MFA enforcement across directories or identity providers, and a formally approved risk register detailing any accounts bypassing the requirement.

MFA exceptions should be submitted with a risk rationale, approved by senior leadership, logged in a central risk register, and reviewed at least annually to determine if technical upgrades now permit MFA implementation.

Phishing-resistant MFA relies on hardware tokens or passkeys (such as FIDO2) that cryptographically bind the authentication attempt to a specific site, preventing interception. While basic MFA meets the baseline standard, implementing phishing-resistant MFA is highly recommended for strong enterprise security.

This control is easiest to sustain when MFA coverage and exceptions are treated like living compliance evidence, not a one-time project. Tools like WatchDog Security's Compliance Center can help map the requirement to systems and evidence, highlight gaps (e.g., apps or accounts not covered by MFA), and maintain an audit-ready record of what was tested and when.

MFA exceptions should be handled as explicit risk acceptances with a clear owner, rationale, compensating controls, and a review date so they don’t become permanent. Tools like WatchDog Security's Risk Register can centralize exception entries, track approvals and renewals, and tie each exception to residual risk and remediation plans for audit evidence.