Companies have included multi-factor authentication (MFA) or 2FA in their systems to secure their data and customers’ privacy, yet issues are still encountered upon deploying.

When initially deploying any form of MFA, enterprises will experience pushback from any users who have limited experience with cybersecurity and view the addition of extra security measures as a speedbump to them doing their assigned work.

These users will tend to fit the profile of those who moan about password complexity or who’ve taken to keeping passwords on sticky notes under their keyboards.

The easiest way to resolve this situation is through education covering real-world examples of cyber incidents where MFA could’ve assisted in containing or preventing the breach. Once past the initial pushback the next hurdle are users who feel entitled to avoid MFA for a seemingly cogent argument.

This could be accounts to be used only if there are operational issues with the MFA implementation – e.g. if MFA is offline, such accounts could be used to manage the system. While there will always be scenarios where offline management is required, the use of such accounts in daily operations is to be avoided and as a result strong audit measures should be in place.

While MFA presumes the user has multiple independent means to identify themselves, care should be taken to avoid single points of failure in the design. For example, if the second identification form is a code sent to a mobile device and the user is logging in on the same mobile device, does the use of a text message effectively remove one of the authentication factors? Lastly, the use of MFA while connected to an internal network should be carefully evaluated. This is the area most prone to user pushback.

A properly designed MFA model will assume employees will have some variant of a’ bring-your-own’ (BYO) model in place. This could be a personal cell phone, or a home computer used when a corporate issued device isn’t available.

By following a BYO paradigm, an effective zero-trust boundary can be created which presumes that access to any system via an external network must use multiple factors. It also gives a level of flexibility to the authentication design for aspects such as VPN access or whether certain security profiles are enabled on the mobile device.

Additionally, the zero-trust paradigm then flows into access controls around specific datasets allowing for more sensitive actions likes write or delete access to be appropriately managed. As with all authentication models, auditing should be enabled at all levels, but with a BYO paradigm care should be taken to ensure that any single points of failure are minimised. This is due to the lack of control over the device and that the device might actually support multiple users.

Put another way, in a shared use environment mitigating the risk of pre-authorized cached access to resources could create a threat vector resulting from access. This is why all MFA implementations should go through a comprehensive threat assessment.