How to Set Up MFA for Your Organization: A SkyCore Solutions Guide

Step 1: Understand MFA Concepts and Verification Methods

Before diving into configuration, a foundational understanding of MFA principles and the various authentication methods is critical. MFA works by requiring two or more independent forms of identification, typically drawing from three categories: something you know (e.g., a password), something you have (e.g., a trusted device or hardware key), and something you are (e.g., a fingerprint or face scan). This multi-modal approach significantly raises the bar for attackers, as compromising a single factor is no longer sufficient.

Microsoft Entra ID supports a wide array of verification methods. The strength and usability of these methods vary, and your choice impacts both security and user experience. NIST SP 800-63-3, Digital Identity Guidelines, categorizes authenticators by assurance level (AAL), emphasizing cryptographic-based solutions for higher security. CISA also advocates for "phishing-resistant MFA" methods.

• Microsoft Authenticator: SkyCore's top recommendation for flexibility, usability, and security. It offers passwordless sign-in, push notifications, and OATH codes, and meets NIST AAL2 requirements.
• FIDO2 Security Key (Passkey): Highly secure and phishing-resistant, meeting NIST AAL2/AAL3. Excellent for high-privilege accounts.
• Windows Hello for Business: Biometric or PIN-based authentication for Windows devices.
• OATH Hardware/Software Tokens: Time-based One-Time Password (TOTP) generators.
• SMS Verification: While widely available, both NIST SP 800-63-3 and CISA recommend against SMS for higher assurance levels due to its susceptibility to SIM-swapping and other interception attacks. SkyCore Solutions advises disabling SMS for general use in favor of stronger methods.
• Voice Call Verification: Similar to SMS, voice calls are generally considered less secure than app-based or hardware token methods due to potential social engineering or telephony network vulnerabilities. SkyCore Solutions advises disabling this method.
• Temporary Access Pass (TAP): A time-limited, single-use passcode used for onboarding or account recovery, offering a flexible, temporary strong credential.

Your strategy should prioritize methods that offer strong security (e.g., Microsoft Authenticator push notifications, FIDO2) while balancing user experience. Ensure you enable more than one method so users have a backup if their primary method is unavailable.

Step 2: Plan Your MFA Strategy: Security Defaults vs. Conditional Access

Microsoft Entra ID offers two primary mechanisms for enforcing MFA: Security Defaults and Conditional Access policies. Choosing the right one depends on your organization's licensing, desired granularity, and risk profile. SkyCore Solutions strongly recommends Conditional Access for most organizations due to its flexibility and advanced capabilities.

Security Defaults

Security Defaults provide a baseline level of security for all Microsoft Entra tenants. They enforce MFA for all users and administrators, block legacy authentication protocols, and require users to register the Microsoft Authenticator app. Tenants created after October 2019 typically have Security Defaults enabled by default. This is a quick win for basic protection, but offers no granular control over who, what, when, or where MFA is prompted.

Portal alternative: To check or change the status of Security Defaults:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Overview > Properties.
3. Scroll down and select Manage Security defaults.
4. Toggle "Enable Security defaults" to Yes or No as required.

Conditional Access Policies (SkyCore Recommendation)

Conditional Access, requiring a Microsoft Entra ID P1 or P2 license, offers precise control over MFA enforcement. It allows you to define policies based on specific conditions:

• Users and Groups: Target specific users, groups (e.g., administrators, finance department), or exclude break-glass accounts.
• Cloud Apps or Actions: Require MFA for specific applications (e.g., SharePoint, Exchange Online, CRM) or sensitive actions (e.g., Azure management).
• Conditions:
• Sign-in risk: Integrate with Microsoft Entra ID Protection to trigger MFA for risky sign-ins (e.g., from anonymous IP addresses, atypical locations).
• Device state: Require MFA if a device is not compliant or not hybrid Azure AD joined.
• Location: Prompt MFA when users sign in from outside trusted network locations (Named Locations).
• Client apps: Apply policies based on client application type (e.g., browser, mobile apps, legacy authentication clients).

SkyCore Solutions highly recommends Conditional Access due to its ability to enforce MFA only when needed for security, minimizing friction for users when they are on trusted devices or networks.

Step 3: Disable Legacy Per-User MFA and Security Defaults (If Transitioning)

If your organization is transitioning to Conditional Access policies, it is imperative to disable any existing legacy per-user MFA configurations and, if enabled, Security Defaults. Conditional Access policies will not function as expected, or may conflict, if these older mechanisms are still active. Many tenants created after 2019 will not have legacy per-user MFA enabled, but it's crucial to confirm.

To disable Legacy Per-User MFA:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Users > All users.
3. Select Per-user MFA from the top menu.
4. For any users currently enabled for per-user MFA, select them and choose Disable. This can be done in bulk for multiple users.

Note: There is no direct PowerShell or Azure CLI command to disable legacy per-user MFA for all users; it is primarily managed via the administrative UI.

To disable Security Defaults:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Overview > Properties.
3. Scroll down and select Manage Security defaults.
4. Toggle "Enable Security defaults" to No.

Note: Similar to legacy per-user MFA, disabling Security Defaults is primarily a GUI action, although its status can be queried programmatically via Microsoft Graph API.

Step 4: Configure Authentication Methods Policy

With Security Defaults and legacy MFA out of the way, your next step is to define which authentication methods users are allowed to register and use. This is managed via the Authentication Methods policy in Microsoft Entra ID. SkyCore Solutions recommends enabling only the strongest, most user-friendly methods and explicitly disabling weaker options like SMS and Voice calls.

We'll use the Microsoft Graph PowerShell SDK for this configuration, as it offers granular control and is the recommended approach for modern Microsoft Entra administration.

# Ensure the Microsoft Graph PowerShell SDK is installed
Install-Module -Name Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph with necessary permissions
# The Policy.ReadWrite.AuthenticationMethod scope is required to modify authentication methods policies.
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

# --- Step 4.1: Retrieve the existing Authentication Methods Policy ---
# This cmdlet fetches the current authentication method policy configuration.
$authMethodPolicy = Get-MgPolicyAuthenticationMethodPolicy

# --- Step 4.2: Configure Microsoft Authenticator --- 
# SkyCore recommends enabling Microsoft Authenticator for its security and usability.
# We'll enable it for a pilot group first, then expand.

# Filter for the Microsoft Authenticator configuration object
$microsoftAuthenticatorConfig = $authMethodPolicy.AuthenticationMethods | Where-Object { $_.ODataType -eq "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration" }

# Enable the Microsoft Authenticator method
$microsoftAuthenticatorConfig.State = "Enabled"

# Scope Microsoft Authenticator to a pilot group initially.
# Replace '<YourPilotGroupId>' with the actual GUID of your Microsoft Entra security group for pilot users.
$microsoftAuthenticatorConfig.IncludeTargets = @(
    @{ 
        targetType = "group"; 
        id = "<YourPilotGroupId>"; 
        isBackup = $false 
    }
)

# ExcludeTargets is optional; use if you need to exclude specific groups from this method.
$microsoftAuthenticatorConfig.ExcludeTargets = @()

# --- Step 4.3: Disable SMS Verification --- 
# As per NIST and CISA recommendations, SMS verification is less secure. SkyCore advises disabling it.

# Filter for the SMS Authentication Method configuration object
$smsConfig = $authMethodPolicy.AuthenticationMethods | Where-Object { $_.ODataType -eq "#microsoft.graph.smsAuthenticationMethodConfiguration" }

# Disable the SMS authentication method for all users
$smsConfig.State = "Disabled"
# When disabled for all, includeTargets and excludeTargets are typically empty or not set.
$smsConfig.IncludeTargets = @()
$smsConfig.ExcludeTargets = @()

# --- Step 4.4: Disable Voice Call Verification --- 
# Voice calls also carry inherent security risks and should be disabled.

# Filter for the Voice Call Authentication Method configuration object
$voiceConfig = $authMethodPolicy.AuthenticationMethods | Where-Object { $_.ODataType -eq "#microsoft.graph.voiceAuthenticationMethodConfiguration" }

# Disable the Voice Call authentication method for all users
$voiceConfig.State = "Disabled"
$voiceConfig.IncludeTargets = @()
$voiceConfig.ExcludeTargets = @()

# --- Step 4.5: Update the Authentication Methods Policy ---
# Construct the body for the update request with the modified configurations.
$updatedAuthMethods = @($microsoftAuthenticatorConfig, $smsConfig, $voiceConfig)

# This cmdlet applies the changes to the Authentication Methods policy.
Update-MgPolicyAuthenticationMethodPolicy -AuthenticationMethods $updatedAuthMethods

# To verify the changes, you can run:
# Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethods

• Install-Module -Name Microsoft.Graph -Scope CurrentUser: Installs the Microsoft Graph PowerShell SDK for the current user.
• Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod": Connects to Microsoft Graph with permissions to read and write authentication method policies.
• Get-MgPolicyAuthenticationMethodPolicy: Retrieves the current global authentication methods policy.
• `$authMethodPolicy.AuthenticationMethods | Where-Object { $_.ODataType -eq "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration" }`: Filters the policy to target the specific Microsoft Authenticator configuration object.
• `$microsoftAuthenticatorConfig.State = "Enabled"`: Sets the state of the Microsoft Authenticator method to enabled.
• `$microsoftAuthenticatorConfig.IncludeTargets = @(...)`: Specifies a Microsoft Entra security group by its GUID for which this method will be enabled. This is crucial for pilot programs.
• `$smsConfig.State = "Disabled"` and `$voiceConfig.State = "Disabled"`: Explicitly disables SMS and Voice call verification for all users, aligning with security best practices.
• `Update-MgPolicyAuthenticationMethodPolicy -AuthenticationMethods $updatedAuthMethods`: Applies all the modified authentication method configurations back to the policy.

Portal alternative:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Protection > Authentication methods > Policies.
3. Select each method (e.g., "Microsoft Authenticator", "SMS", "Voice call") to configure its state (Enabled/Disabled) and target users/groups.

After running the commands, verify the status by running `Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethods` to confirm your changes.

Step 5: Create Conditional Access Policies for MFA Enforcement

Now that you've defined *what* authentication methods are allowed, it's time to define *when* MFA is required. Conditional Access policies are the bedrock of granular, intelligent MFA enforcement. SkyCore Solutions always advocates for a phased rollout, starting with administrators and a pilot group, and utilizing "Report-only" mode initially.

We'll use Azure CLI to create a foundational Conditional Access policy.

# Ensure Azure CLI is installed and the conditional-access extension is added
az extension add --name conditional-access

# Log in to Azure CLI (if not already logged in)
az login

# --- Step 5.1: Create a Conditional Access Policy for Administrators (Pilot) ---
# This policy targets a specific group of administrators and requires MFA.
# It's initially set to 'enabledForReportingOnly' for testing.

# Replace '<AdminPilotGroupId>' with the GUID of your Microsoft Entra security group containing pilot administrators.
# Replace '<YourTrustedNamedLocationId>' with the ID of your Named Location for trusted networks, if applicable.
# If you don't have Named Locations, you can omit the --locations-excluded-locations parameter initially.

az conditional-access policy create \
    --name "SkyCore - MFA for Administrators (Pilot)" \
    --state "enabledForReportingOnly" \
    --conditions-users-included-groups "<AdminPilotGroupId>" \
    --conditions-applications-included-sign-in-audience "all" \
    --grant-controls "mfa" \
    --conditions-client-app-types "all" \
    --locations-excluded-locations "<YourTrustedNamedLocationId>" \
    --session-controls-sign-in-frequency "7.00:00:00"

# Explanations:
#   --name: A descriptive name for your Conditional Access policy.
#   --state "enabledForReportingOnly": Critical for initial deployment. The policy is evaluated but not enforced, allowing you to review its impact in the sign-in logs without affecting users. Switch to "enabled" after testing.
#   --conditions-users-included-groups "<AdminPilotGroupId>": Targets specific users or groups (identified by GUID) for this policy. Start with a small pilot group, especially for administrators.
#   --conditions-applications-included-sign-in-audience "all": Applies the policy to all cloud applications. Can be narrowed to specific apps by using their application IDs.
#   --grant-controls "mfa": The access control to enforce, in this case, Multi-Factor Authentication.
#   --conditions-client-app-types "all": Applies the policy to all client application types (browsers, mobile apps, desktop clients, legacy clients).
#   --locations-excluded-locations "<YourTrustedNamedLocationId>": Excludes a specific Named Location (e.g., your corporate office IP ranges) from requiring MFA. This improves user experience on trusted networks. You must create Named Locations first.
#   --session-controls-sign-in-frequency "7.00:00:00": (Optional) Requires users to re-authenticate (potentially with MFA) every 7 days, even if their session is still active.

# --- Step 5.2: (Optional) Create a Policy for All Users Requiring MFA for Critical Apps ---
# This example demonstrates targeting specific applications rather than all apps.
# Replace '<AllUsersGroupId>' with the GUID of your 'All Users' group or a larger pilot group.
# Replace '<SharePointOnlineAppId>' and '<ExchangeOnlineAppId>' with the actual Application IDs of SharePoint Online and Exchange Online (these are standard).

az conditional-access policy create \
    --name "SkyCore - MFA for All Users to Critical Apps (Report-only)" \
    --state "enabledForReportingOnly" \
    --conditions-users-included-groups "<AllUsersGroupId>" \
    --conditions-applications-included-apps "00000003-0000-0ff1-ce00-000000000000" "00000002-0000-0ff1-ce00-000000000000" \
    --grant-controls "mfa" \
    --conditions-client-app-types "all"

# Note: '00000003-0000-0ff1-ce00-000000000000' is the App ID for Microsoft SharePoint Online.
# '00000002-0000-0ff1-ce00-000000000000' is the App ID for Microsoft Exchange Online.

Portal alternative:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Conditional Access > Policies.
3. Select New policy.
4. Configure Users, Target resources (Cloud apps or actions), Conditions (User risk, Device platforms, Locations, Client apps), and Grant (Require multi-factor authentication).
5. Set Enable policy to Report-only initially for testing.

After creating your policies, monitor their impact in the Sign-in logs (Identity > Monitoring & health > Sign-in logs) for any "Report-only" policies. This allows you to fine-tune before full enforcement.

Step 6: User Registration and Onboarding

Once Conditional Access policies are in place, users will be prompted to register their MFA methods upon their next sign-in if they fall within the scope of an enforced policy. Effective communication and a clear onboarding process are vital for successful user adoption.

There are no direct CLI commands for the user-facing registration process itself, as this is an interactive workflow for the user.

User Guidance Best Practices:

• Pre-Communication: Inform users well in advance about the upcoming MFA rollout. Explain what MFA is, why it's being implemented (security benefits), and what they can expect.
• Step-by-Step Instructions: Provide clear, concise instructions on how to register their chosen MFA method, particularly for the Microsoft Authenticator app. Direct them to aka.ms/mfasetup for guided registration.
• Encourage Strong Methods: Actively encourage users to register and use the Microsoft Authenticator app (push notifications) or a FIDO2 security key over less secure methods.
• Support Plan: Have a clear support channel for users who encounter issues during registration or sign-in.

Using Temporary Access Pass (TAP) for Onboarding and Recovery

Temporary Access Pass (TAP) is an excellent tool for onboarding new users, recovering accounts, or providing temporary access when a user's primary MFA method is unavailable.

# Connect to Microsoft Graph with necessary permissions
# The User.ReadWrite.All and AuthenticationMethod.ReadWrite.All scopes are needed.
Connect-MgGraph -Scopes "User.ReadWrite.All", "AuthenticationMethod.ReadWrite.All"

# --- Create a Temporary Access Pass (TAP) for a specific user ---
# Replace '<UserIdOrPrincipalName>' with the user's User Principal Name (UPN) or Object ID.

$tapParams = @{
    IsUsableOnce = $true         # Set to $true for a single-use TAP; $false allows multiple uses during its lifetime.
    LifetimeInMinutes = 60       # The TAP will be valid for 60 minutes. Max is 4320 minutes (3 days).
    # StartDateTime = (Get-Date).ToUniversalTime() # Optional: Specify a start time; defaults to now.
}

New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "<UserIdOrPrincipalName>" -Body $tapParams

# Example Output (Note: The RawTemporaryAccessPass property contains the actual TAP value):
# CreationDateTime          : 7/7/2026 10:00:00 AM
# Id                        : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# IsUsableOnce              : True
# LifetimeInMinutes         : 60
# MethodEnabled             : True
# ObjectId                  : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# RawTemporaryAccessPass    : ABCDEF1234567890
# StartDateTime             : 7/7/2026 10:00:00 AM
# State                     : Active
# UserId                    : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• Connect-MgGraph -Scopes "User.ReadWrite.All", "AuthenticationMethod.ReadWrite.All": Connects to Graph with permissions to manage user authentication methods.
• IsUsableOnce = $true: Defines if the TAP can be used only once (recommended for security) or multiple times within its lifetime.
• LifetimeInMinutes = 60: Sets the validity period for the TAP. SkyCore recommends a short lifetime (e.g., 30-60 minutes) for security.
• New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "<UserIdOrPrincipalName>" -Body $tapParams: Creates the TAP for the specified user. The actual passcode is returned in the `RawTemporaryAccessPass` property.

Portal alternative for TAP:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Users > All users.
3. Select the target user.
4. Under Authentication methods, select Add authentication method.
5. Choose Temporary Access Pass (Preview) and configure its properties.

Step 7: Monitoring and Refinement

Deploying MFA is not a one-time task; it requires continuous monitoring and refinement. Regularly review your sign-in logs, audit Conditional Access policies, and gather user feedback to ensure optimal security and user experience.

Monitoring Sign-in Logs:

Sign-in logs provide invaluable insights into how your MFA policies are being applied and if there are any issues.

Portal recommended for comprehensive sign-in log analysis:

1. Go to the Microsoft Entra admin center.
2. Navigate to Identity > Monitoring & health > Sign-in logs.
3. Use the filtering options to review sign-ins:
• Filter by Conditional Access to see policies applied and their results.
• Filter by MFA requirement to see where MFA was required, granted, or denied.
• Filter by Status to identify failed sign-ins and investigate the reasons.
• Look specifically for "Report-only" results to evaluate the impact of your pilot policies before enforcing them.

While the Azure CLI can query activity logs, the granularity for specific MFA and Conditional Access details is best viewed and analyzed within the Microsoft Entra admin center or via the Microsoft Graph API for programmatic access to detailed sign-in event data.

Policy Refinement:

• Transition from Report-only: Once you are confident with the impact of your Conditional Access policies based on sign-in log analysis, switch their state from "Report-only" to "Enabled."
• Expand Scope: Gradually expand the scope of your MFA policies from pilot groups to broader user populations.
• Review Authentication Methods: Periodically review the Authentication Methods policy to ensure only desired and secure methods are available. Disable any methods that become deprecated or are deemed insecure.
• User Feedback: Solicit feedback from users. Address common pain points while balancing security requirements.
• Risk-based Policies: If using Microsoft Entra ID Protection, leverage risk-based Conditional Access policies to dynamically require MFA or even block access based on real-time risk detections (e.g., leaked credentials, sign-ins from anonymous IP addresses).