MFA Configuration: How Automation Lets You Configure & Enforce MFA Compliance at Scale

You probably used multi-factor authentication (MFA) to access the device you’re using right now. Maybe your phone scanned your face or fingerprint to unlock. Maybe you got a text with a verification code while logging into your work browser profile. Configuring MFA is a go-to measure for system hardening, but MFA enforcement can get unruly, especially at the scale required by enterprise IT.

In this post, I’ll offer an overview of MFA configuration, including best practices, use cases, the place of MFA in compliance, and how Puppet provides the backbone of an MFA enforcement policy for enterprise IT.

What is MFA (Multi-Factor Authentication)?

Multi-factor authentication (MFA) is an IT security mechanism that requires users to provide at least two forms of verification to access a system, application, or data. MFA involves a combination of something the user knows (their password), something the user has (like a smartphone or other device authentication token), and something they are (a personal signifier like a fingerprint or facial recognition).

MFA makes it a lot harder for unauthorized individuals to gain access to a system because it requires a user to provide multiple identifiers, instead of just a password. Compromised passwords are a common entry point for attacks and unauthorized access to a network, so MFA has become a necessary security measure in modern IT. It’s also a best practice for system hardening and a core tactic for zero-trust security policy enforcement, making it a common requirement for many compliance standards and regulations.

MFA vs. 2FA: What’s the Difference?

While often used as interchangeable terms, the simple difference between multi-factor authentication (MFA) and two-factor authentication (2FA) is the number of authentication methods required by each. While 2FA requires exactly two authentication methods, MFA requires two or more.

The authentication methods available with MFA and 2FA are the same — they can both use factors like a password, hardware key, verification code, fingerprint, or face scan — but the difference is in how many each requires before allowing access. Because MFA requires two or more authentication factors, it’s considered a more secure identity authentication method than 2FA.

Learn how Puppet agent-based automation works around the clock to keep security configurations like MFA and 2FA consistent and help DevOps teams achieve continuous compliance >>

Note that each chosen method must come from a different category. For example, entering two passwords and a PIN (all are things you know) is considered multi-verify and not satisfactory for either 2FA or MFA.

Why Do We Need MFA?

Multi-factor authentication helps keep systems secure by enforcing higher standards of access security than traditional single-authentication methods. MFA is important for any organization’s IT, but especially those that handle sensitive or proprietary information like company secrets, health records, financial data, and other personally identifiable information (PII).

MFA is also a core requirement or best practice for many compliance frameworks and regulations. (More on those below.)

MFA Compliance: Frameworks & Regulations to Know

Many of the world’s best known compliance frameworks and laws require MFA, including HIPAA, NIST, PCI DSS, CCPA, and NIS2. These standards either require MFA by name or recommend it implicitly by requiring ‘strong access controls’.

Because it’s such an effective way to authenticate identity for system access, MFA is a key expectation of many compliance frameworks, standards, and regulations across the globe. Here’s just a sample: 

Choosing Multi-Factor Authentication Tools for Enterprise Organizations

Common tools for doing MFA in an enterprise setting include Okta, Google Authenticator, Microsoft Authenticator, Cisco DUO, LastPass, and Authy. Enterprise features typically include centralized management, multi-device support, IAM integration, and more.

Choosing an MFA tool (or multiple MFA tools) for enterprise IT systems ultimately comes down to an evaluation of the features of each. How well suited is it to your specific needs? Can it keep up when those needs change (like if you migrate away from cloud or expand your IT estate)?

No matter which MFA tool you choose, keep it configured just the way you want it with desired state automation from Puppet Enterprise >>

In the interest of providing helpful guidance without pointing you toward one branded tool or another, here are some considerations for picking an enterprise MFA tool:

• Centralized Management: MFA tools with an administration console for common tasks – like provisioning and deprovisioning users, managing users or tokens, monitoring usage, or recovering tokens for users who lose their devices – can streamline enterprise MFA for easier, more efficient enforcement.
• Multi-Device Support: Look for tools with support for synchronization across multiple devices. If a user changes or loses their device (common in an enterprise setting), they’ll need an efficient method to recover their tokens without relying on backup codes or resetting the 2FA setup on the relevant accounts.
• Support for High-Availability: Enterprises often require high availability and redundancy for critical security tools in case of disaster and need for backup. Select solutions with built-in redundancy or failover mechanisms.
• Integration with Enterprise Identity and Access Management (IAM): Deep integration with enterprise IAM solutions or other security infrastructure like Single Sign-On (SSO) or Privileged Access Management (PAM) systems.
• Service-Level Agreements (SLAs): Enterprises typically require support guarantees, especially when it comes to security tools.

What Makes an MFA Enforcement Policy Essential for Enterprise IT

Enforcing MFA at scale presents several challenges that make it difficult to maintain MFA configurations in an enterprise environment. Those challenges can include heterogeneous environments (OSes) with different capabilities and requirements, legacy systems, varied user roles and needs, scalability, and decentralized MFA policy management.

Configuring MFA with your tool of choice is all well and good, but no system hardening measure is set-it-and-forget-it. That’s especially true of the large, complex IT environments that enterprise organizations rely on. At the same time, those types of organizations often manage extremely sensitive data — making MFA both a requirement and a challenge for enterprises.

As your IT environment grows (more servers, more users, more access points), the struggle to maintain security and compliance multiplies. Consider a few of the ways enterprise IT makes it particularly hard to enforce consistent MFA measures:

Heterogeneous Environments, Multiple OSes, and Legacy Systems

Enterprise organizations are often running multiple operating systems and a wide variety of applications across a huge number of machines. And that’s not to mention the fact that IT is often expected to support legacy versions of enterprise software for business continuity, compatibility, and stability.

Each of those has its own capabilities and requirements for configuring MFA, which can get hairy. For example, an enterprise organization might use…

• Microsoft Authenticator for Windows workstations and cloud
• Amazon’s MFA product for Amazon Web Services (AWS) platform access
• Cisco’s Duo Security for database and enterprise apps
• Okta for remote access and VPN
• Google Authenticator for Google Workspace

Manually installing and configuring each of those MFA products and services is just the start of the enterprise MFA struggle — let alone trying to enforce a uniform MFA policy you can control, adjust, and report on easily.

The Challenges of MFA vs. 2FA in Enterprise IT

For practical reasons, Linux authentication methods (especially for remote access via SSH) are usually 2FA instead of MFA because it usually requires interaction with a terminal or console. This can result in inconsistent MFA policy enforcement in IT systems where Linux is used alongside other OSes (like Windows and macOS).

Accommodating a Wide Variety of User Roles

The volume of people who need access to your system can get really big at enterprise scale. Different types of users may need different types of access, from employees and admins to contractors and third parties. This breadth of roles needs to be considered when developing an MFA policy in an enterprise organization, typically by leveraging role-based access control (RBAC) to create and enforce MFA policies.

For example, you might require strict MFA for users connecting to the network remotely via VPN, but not for users who work in the office and connect directly. Or you might be asked to enforce more adaptive MFA measures for administrative staff, based on their location or behavior.

Decentralized MFA Configuration Management

Centralized management of MFA configuration is one of the largest obstacles for enterprises MFA enforcement. i.e., How does an individual user set up their authenticator app for a given login? Without centralized control over how users configure and use their authenticators, inconsistency can lead to security gaps and compliance violations.

Compounding the problem of heterogeneous, diverse IT environments, enterprise IT rarely has the luxury of a single source of truth or a single pane of glass for managing configurations like MFA. That means your team might have to access different resources to monitor, configure, and enforce authentication methods in different parts of the same system.

An MFA Enforcement Policy for Enterprise IT Relies on Policy as Code

An MFA enforcement policy is a set of rules, guidelines, and practices associated with configuring and maintaining consistent multi-factor authentication measures across an IT system. Policy as code (PaC) can be used to enforce consistent MFA policies by defining IAM rules as code that can be version controlled, automated, and enforced uniformly across different applications and OSes.

Policy as code (PaC) is a method of writing infrastructure as code (IaC) to align infrastructure configurations (including system hardening measures) with your IT rules, industry best practices, and external compliance standards. PaC relies on automation and configuration management to define, configure, and remediate infrastructure code to a desired state in alignment with your security and compliance policies.

How PaC is Used for MFA Policy Enforcement

PaC can be used to enforce MFA policies consistently across an enterprise IT environment. Systems, users, roles, MFA tools, conditions, exceptions — with policy as code, those configurations are all defined in a single source of truth (your infrastructure code). That way, you’ve got a single pane of glass for reviewing, auditing, updating, and correcting your MFA policy.

• Policy as code provides a definitive, centralized source of configuration truth for enforcing an MFA policy in enterprise IT. It’s literally code that expresses your infrastructure configurations, so it can be versioned with tools like Perforce and Git to track changes over time.
• Writing your MFA policies as code means you can manage configurations for multiple MFA mechanisms across different OSes and applications from one place. Vendor-neutral PaC tools like Puppet aren’t tied to a small set of platforms or deployment models.
• Policy as code can play a crucial role in ensuring that an authenticator can reach the identity provider (IdP). PaC can configure make sure that the services necessary for communication between the authenticator (like Google Authenticator) and its IdP are running and properly configured; it makes sure the server can resolve the IdP’s address through DNS; and it can distribute certs to maintain trust between the authenticator and IdP for secure communication.  
• Policy as code lets you integrate MFA policies into your CI/CD pipelines, which helps you ensure that your required MFA policies are in place every time you make a change to your infrastructure code (and block deployment until you can ensure the change complies with your policies).

Policy as Code Example for Creating an MFA Enforcement Policy

Write Your MFA Policy as Code

First, your infrastructure or automation engineer would write the code that says all users accessing critical systems must use MFA. In Puppet, that’d be in Puppet’s domain-specific language (DSL), a declarative code language based in Ruby.

Test & Deploy Your MFA Policy

With your declarative infrastructure code in hand, you can integrate the policy into your CI/CD pipeline for testing, delivery, and deployment to the target environment(s) where you need your MFA policy enforced.

Automatically Enforce Your MFA

Your automation and configuration management tool will use the deployed infrastructure code to automatically apply the policy across your environment and ensure MFA is required everywhere you want it to be.

Automatic Monitoring & Drift Correction

An agent-based automation and configuration management tool will continuously monitor your systems for compliance with the MFA policy and correct any drift or unauthorized changes. Every time an approved change is deployed, each automation agent will request a new code deployment to bring its server into compliance with your updated MFA policy.

Using Puppet Policy as Code for MFA Enforcement

Puppet’s combination of a declarative coding language and agent-based automation makes it the only solution capable of enforcing policy as code at all times on all systems. That includes routine assessment of infrastructure configurations, like MFA, as well as round-the-clock enforcement and remediation.

• Agent-based automation executes configuration automation locally — as in, on the server itself, rather than on a remote host — so you can use Puppet to manage different MFA tools on Windows, Linux, and macOS servers as part of the same infrastructure management tooling.
• Agent-based automation also means Puppet can enforce configurations more securely during network outages, since it doesn’t rely on network connectivity (like SSH) to request and deploy infrastructure code.
• Puppet runs every 30 minutes by default — 48 times every single day — and Bolt can be used to run ad hoc tasks on command, leaving zero gaps in your security and compliance configuration.
• Puppet also lets you code custom exceptions into your blanket MFA enforcement policy to account for the unique cases and idiosyncrasies that often arise in enterprise IT environments. (Puppet will enforce those rules just the same until you merge new code with your Puppet codebase.)

Security Compliance Enforcement for MFA

Security Compliance Enforcement is a premium feature for Puppet that uses pre-built blocks of Puppet code to automatically remediate infrastructure security configurations to baselines hardened aligned to CIS Benchmarks and DISA STIGs. That includes support for numerous configurations at the server, OS, and app level.

Available for every Puppet license (including Open Source Puppet), Security Compliance Enforcement simplifies the complex world of compliance by automatically keeping you in check with the most widely accepted security best practices. Security Compliance Enforcement is also included with a Puppet Enterprise Advanced license, along with every time-saving Puppet premium feature — perfect for large-scale infrastructure management.

Puppet ensures there are no gaps in your MFA enforcement, meaning you can treat security and compliance as a rule — not just a goal.

For more on Puppet and Security Compliance Enforcement, request a demo with our team today. To learn more about the use case of automation in ensuring security and compliance across big, complex IT estates, download our informative white paper at the link below.

DEMO PUPPET   GET WHITE PAPER