Implementation of multi-factor authentication

Why passwords are not sufficient protection

Passwords are reused, compromised via phishing pages, guessed, or obtained through breaches of other services. Even a robust complex password policy does not eliminate the risk of an employee entering their credentials into a convincing-looking fake login screen. The attacker then possesses valid credentials and can often impersonate a legitimate user without immediately triggering an alert.

MFA adds a second verification step. If the password is compromised, the login attempt remains blocked unless the attacker also has access to the second factor. This does not make the organization invulnerable—attacks involving fraudulent notification approval, session hijacking, and social engineering remain possible. However, it eliminates the most common and easily exploited pathway into corporate accounts.

The benefits are particularly significant for platforms storing large volumes of business data: email, Microsoft 365 or Google Workspace, VPNs, accounting systems, CRMs, remote access systems, and administrative panels. A compromised email account, for instance, can be used to send fraudulent payment instructions, intercept correspondence, and reset passwords for other services.

Prioritized implementation of multi-factor authentication

An effective implementation project does not begin by enabling MFA for all applications simultaneously. It starts with a review of access rights, data, and actual workflows. The goal is to first secure the systems where a breach would pose the greatest financial, operational, or reputational risk.

The typical first stage covers administrator accounts, email, cloud platforms, VPN access, and remote support systems. Administrator accounts must be treated separately from standard user accounts; they possess elevated privileges and should not be used for day-to-day email or web browsing.

Next, the scope extends to employees with access to sensitive information—such as financial data, HR records, contracts, customer data, and management reports. For organizations with multiple applications, it is necessary to verify whether each system supports MFA directly or via a centralized identity service. This review often uncovers legacy accounts, shared user accounts, and applications lacking a clear owner—issues that MFA alone cannot resolve.

Mapping users, devices, and access

Before implementation, it is essential to have an up-to-date list of users, roles, devices in use, and critical applications. You need to identify who works from the office, who works remotely, who uses a personal phone, and which external partners have access to corporate systems.

This is also the time to remove inactive accounts and restrict excessive access rights. While multi-factor authentication secures the login process, it does not rectify access granted to the wrong person or access that remains active after an employee has left. Best practice dictates that access should be tied to a specific job role and reviewed periodically.

Which method is right for your organization?

Not all second-factor methods offer the same level of security and convenience. The choice depends on the number of users, the criticality of the systems, field operations, the availability of company-issued phones, and compliance requirements.

SMS codes are easy to enter and can serve as a transitional solution, but they are less secure than an authentication app. A phone number can be fraudulently transferred to another mobile carrier, and messages do not always arrive on time when traveling or in areas with poor signal coverage. Therefore, it is prudent to retain SMS only as a limited backup method rather than as the primary standard for critical systems.

Authentication apps generate one-time codes or send approval notifications. While convenient for most employees, notifications should be paired with an additional verification step—such as entering a number displayed on the login screen. This mitigates the risk of a user approving a series of fraudulent notifications simply to stop them.

Hardware keys are best suited for administrators, management, and users with access to highly sensitive data. They offer superior resistance to phishing but require processes for issuance, storage, and replacement in the event of loss. In some cases, a hybrid approach is optimal: using an app for general users and hardware keys for privileged roles.

Plan for exceptions before they become incidents

The most common operational challenge is not the implementation of MFA itself, but the lack of a plan for exceptions. What happens if an employee changes their phone? How is access restored if a hardware key is lost? How are on-call teams handled when they need to respond outside of business hours? These answers should be defined in advance rather than improvised while access is blocked.

A secure account recovery process is essential. It must include reliable identity verification, clearly defined points of contact, and a record of the actions taken. Temporarily disabling MFA without verification is a convenient but dangerous workaround that can undermine the entire policy.

Shared accounts for devices, applications, or external services require special attention. Whenever possible, these should be replaced with individual user profiles. If they cannot be eliminated for technical reasons, access to them should be restricted, monitored, and kept separate from standard user accounts.

Pilot group before mass rollout

A pilot phase allows you to identify real-world challenges without disrupting the entire organization. An ideal pilot group includes the IT team, administrative representatives, remote workers, and users of critical business applications. They can test various devices, networks, and login scenarios.

During the pilot, the process measures not only technical outcomes but also the workload placed on the helpdesk team. If many users struggle to register the app, misunderstand notifications, or lose access after changing phones, the instructions and process need improvement before a full rollout.

Communication with employees should be concise and specific: explain why the change is being made, what actions are required and by when, and whom to contact in case of issues. Explaining that MFA protects their personal professional identity is usually more effective than a generic warning about cyber threats.

Conditional Access and Risk-Based Control

Following the initial rollout, MFA can become part of a more precise conditional access policy. For instance, the organization might require additional verification when a login originates from a new country or an unmanaged device, or when there is an attempt to access sensitive data. It can also block legacy authentication protocols that do not support MFA.

These rules must be implemented carefully. An overly strict policy can hinder the legitimate work of sales staff, mobile teams, or external accountants, while a policy that is too lax leaves unnecessary security gaps. Striking the right balance requires evaluating roles, data types, and established workflows.

Support, Monitoring, and Periodic Review

MFA is not a "set-and-forget" configuration. It requires monitoring failed login attempts, reviewing the registration of new authentication methods for potential risks, and overseeing changes to administrator accounts. Data from these events helps detect phishing campaigns and unusual behavior before they escalate into security incidents. Backup authentication methods, active devices, and policy exceptions should be reviewed periodically. When an employee leaves, their access and registered methods are removed as part of the standard offboarding process. For new employees, MFA is enabled at the time of account provisioning, rather than weeks later.

For companies lacking the internal capacity to manage this, an external IT partner can handle the assessment, pilot implementation, user support, and security reporting. The role of a team like Helpdesk Bulgaria is not merely to toggle a setting, but to integrate it into a functional process covering identities, devices, access, and incident response.

The best next step is to identify which five accounts would cause the most damage if compromised. If a password alone is still sufficient for them, you have a clear and measurable priority for action.