Cyber Insurance Requiring MFA Everywhere

Cyber insurance providers are tightening their requirements for Multifactor Authentication. For starters, they are being more verbose about the systems and services on which MFA is enabled. They’re making what had been a very broad question into a set of discrete questions. Essentially, what was “Do you have MFA enabled?” is now “Do you have MFA enabled on x, y, and z? 

This blog outlines some of the systems and services commonly asked about in insurance questionnaires. It also suggests ways to address the scenarios, possibly with identity/MFA services that organizations already own. 

Summary of MFA Requirements

In summary, insurers’ questionnaires are now asking about MFA for:

  • All employees when accessing email through a website or cloud-based service
  • All remote access to the network provided to employees, contractors, and 3rd party service providers (both via web and VPN)
  • All internal & remote admin access to directory services (active directory, LDAP, etc.) 
  • All internal & remote admin access to network backup environments
  • All internal & remote admin access to network infrastructure (firewalls, routers, switches, etc.)
  • All internal & remote admin access to the organization’s endpoints/servers

“Can Microsoft’s Identity services meet all of these needs?”

Mostly, but not without some effort. The table below details some of the systems and services about which insurance questionnaires commonly ask. Many scenarios can be covered by Microsoft identity services, many of which organizations already own.

How to Use this Chart

There are two sections, the first for administrators and the second for end-users. On the left-hand side, you’ll see the use cases where Multi-factor Authentication will be required. In subsequent columns, we will articulate if Microsoft has a first party solution for that requirement. The Licensing column articulates the licensing needed to enable the solution, while the Notes/Caveat column points out some key information. The list is not exhaustive but attempts to capture the insurers’ current requirements.

Admin Access

System or Service MSFT Service/Tool Licensing Required Notes/Caveats
Microsoft 365 & Azure Admin Azure AD MFA Free tier of Azure Active Directory Part of automatic Security Defaults; Allows authenticated login, 24/7 (no conditions)
Microsoft 365 & Azure Admin Privileged Identity Management (provides Just-in-Time Access, blocking otherwise) Azure AD P2 License needed for every admin, but not every user
Admin (RDP) access to VMs in Azure Hello for Business on Windows 10 1809 and later Vms on Windows Server 2019 Datacenter and later; Azure AD, Free or Paid Consider Defender for Cloud which provides Just-in-Time access to port 3389 and includes Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP) capabilities ($15/server/month)
Admin access to on-premises Servers (can apply to backup services and network infrastructure (firewalls, routers, switches, etc.) that support AD\AAD authentication or RADIUS) Remote Desktop Services (RDS) infrastructure; Azure AD MFA License; Windows Server software; Network Policy and Access Services (NPS) role; Azure Active Directory synced with on-premises Active Directory; Azure Active Directory GUID ID N/A See "Integrate RDG with Azure AD MFA NPS extension - Azure Active Directory - Microsoft Entra | Microsoft Docs; Third-party options exist as well
Local (console) login to an on-premises Windows Server N/A N/A FIDO2 on Windows Server 2019; Otherwise third-party typically required

User Access to M365 & Cloud Services

System or Service MSFT Service/Tool Licensing Required Notes/Caveats
Microsoft 365 & Exchange Online email user access Azure AD MFA Any Office 365 plan provides basic MFA Insurers have asked about "MFA for Remote Access to email (through a website or cloud service)"; With basic (free) MFA, prompts are more frequent, potentially leading to fatigue
Microsoft 365 user access with Conditional Access (CA) Azure AD MFA with CA Azure AD P1 Once configured, "allow/block decisions" can include location, app, device, and Azure AD-join status
Microsoft 365 user access with ML/AI risk decisions Azure AD Identity Protection Azure AD P2 Once configured, "allow/block decision" include risky behavior assessments (i.e. impossible travel)
User access to 3rd party SaaS Azure AD MFA Azure AD Free (for up to 10 SaaS apps, no SLA); Azure AD P1 (for unlimited apps with SLA) Allows users to login once and, when configured, Azure AD enables SSO to 3000+ web apps
Azure Virtual Desktop Azure AD MFA Azure AD P1 for Conditional Access How often a user is prompted to re-authenticate depends on AAD session lifetime configuration settings

User Access to on-Prem Resources

System or Service MSFT Service/Tool Licensing Required Notes/Caveats
Remote user access to VPN Azure AD MFA Azure AD Free Example: Cisco
Remote user access to app servers on premises Azure AD App Proxy Azure AD P1 or P2 When configured, allows Communicator app to prompt for response prior to granting access to ERPs, web servers, etc.; Requires deployment of AAD AppProxy on a VM
User access to Terminal Server (i.e. RDP into a remote machine) Remote Desktop Services (RDS) infrastructure (on prem or in Azure); Windows Server software; Network Policy and Access Services (NPS) role; Azure Active Directory synched with on-premises Active Directory; Azure Active Directory GUID ID Azure AD P1 (or higher) license See "Integrate RDG with Azure AD MFA NPS extension - Azure Active Directory - Microsoft Enta | Microsoft Docs"; Third-party solutions also available

Conclusion

  1. This list and set of solutions are not completely exhaustive, but it’s meant to provide a checklist and guidance for your next cyber insurance renewal period.
  2. Two things are not (yet) being as discreetly defined:
    1. If remote access is prohibited to on-premises devices by policy or IP restriction, MFA may be excluded on those devices (but check with the insurer).
    2. Alternatively, if admin access is only allowed through a local jump-box computer that does have MFA required, that may circumvent the need to have MFA on the end-server. Again, have the insurance company weigh in.
  3. Start with the biggest attack surface (i.e. users on email being phished) quickly followed by protecting the crown jewels (AD Domain controllers and critical business services).
  4. With North Carolina and other states starting to outlaw (governmental) organizations from paying ransomware pirates, these practices are simply good for business anyway.
  5. Since many of these changes involve a user experience change:
    1. Pilot first (making sure your “break glass” accounts are safe)
    2. Ensure you’re educating users about what will be different, including MFA in the overall cyber training program
  6. Several details / decisions can improve security and/or user friction, such as:
    1. Addressing time to live (TTL) for MFA without requiring reauthentication
    2. Routing remote traffic via VPN connection or by using spilt tunneling?
    3. Developing a process to quickly disable MFA in case a device is lost?
Chris Stegh

Chris Stegh

CTO & VP of Strategy - eGroup | Enabling Technologies