FIPS-140 Compliance mode for Microsoft Windows OS (and Bitlocker) via Intune or GPO

When considering products or services for handling an agency’s information, it is common to see two variations of FIPS accreditation: FIPS validated and FIPS compliant. Although they seem similar, there are different implications with these two labels.

  • FIPS Validation means a product has undergone and passed detailed conformance testing at an accredited national laboratory.
  • FIPS Compliance means that different components of a product have received FIPS validation, but the product in its entirety has not passed testing or has not been tested at all.

Why is being FIPS 140-2 compliant important?

One of the many reasons to become FIPS compliant is due to the government’s requirement that any organization working with them must be FIPS 140-2 compliant. This requirement ensures government data handled by third-party organizations is stored and encrypted securely and with the proper levels of confidentiality, integrity, and authenticity.

Using services or software without these tested methods in place could lead to a massive breach in security, causing problems for every person in the nation.

Who needs to be FIPS compliant?

The main organizations that are required to be FIPS 140-2 compliant are federal government organizations that either collect, store, share, transfer, or disseminate sensitive data, such as Personally Identifiable Information. All federal agencies, their contractors, and service providers must all be compliant with FIPS as well. Additionally, any systems deployed in a federal environment must also be FIPS 140-2 compliant.  Many organizations follow FIPS to ensure their own security is up to par with the government’s security. Many other organizations become FIPS 140-2 compliant to distribute their products and services in not only the United States, but also internationally. As FIPS is recognized around the world, any organization that possesses FIPS compliance will be seen as a trusted provider of services, products, and software. Some fields, such as manufacturing, healthcare, and financial sectors, along with local governments require FIPS 140-2 compliance as well.

Windows Operating System FIPS 140-2 Validation.

Achieving this FIPS 140-2 approved mode of operation of Windows requires administrators to complete all four steps listed in the following article. Federal Information Processing Standard (FIPS) 140 Validation – Windows security | Microsoft Docs

  • Step 1: Ensure FIPS 140-2 validated cryptographic modules are installed
  • Step 2: Ensure all security policies for all cryptographic modules are followed
  • Step 3: Enable the FIPS security policy
  • Step 4: Ensure that only FIPS validated cryptographic algorithms are used

While you may be running the right algorithms, without the Microsoft Validated process in place, you will not be in a validated compliance mode, which could potentially affect your certification process.

Specially for Bitlocker, you can configure the Federal Information Processing Standard (FIPS) setting for FIPS-Mode. As an effect of FIPS compliance, users can’t create or save a BitLocker password for recovery or as a key protector. The use of a recovery key is permitted. However, the policy must be enabled before any encryption key is generated for BitLocker. When this policy is enabled, BitLocker prevents creating or using recovery passwords, so recovery keys should be used instead.

To enable FIPS-Mode, Windows provides the security policy setting, System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing. This setting is used by some Microsoft products to determine whether to run in FIPS mode. When this policy is turned on, the validated cryptographic modules in Windows will also operate in FIPS mode. This policy may be set using Local Security Policy, as part of Group Policy, or through a Modern Device Management (MDM) solution.

As far as Microsoft validations processes for cryptographic algorithms, the cadence for starting module validation aligns with the feature updates of Windows 10 and Windows Server. As the software industry evolves, operating systems release more frequently. Microsoft completes validation work on major releases but, in between releases, seeks to minimize the changes to the cryptographic modules.

ON another note, FIPS 140-2 modules can remain active for five years after validation or until 21 September 2026, when the FIPS 140-2 validations will be moved to the historical list. I am not aware of that validation process for FIPS 140-3 has started or not. However, I don’t expect to see much information available publicly since the current validation process is still active until 2026

For more information about FIPS 140-3, visit the following information.

FIPS 140-3 Transition Effort | CSRC (

RBAC settings required to allow a non-administrator to request or initiate a JIT session

Today, I faced the challenge to grant a remote consultant temporary access to a VM in Azure.

Since, Bastion may be a cleaner way to access the service, we decided to try JIT via the Azure portal as it gives you a quick and easy access protected with MFA. I decided to AZURE AD federations and granted access to his account on his own domain and request MFA (External Access).

After giving the account permission to login to the VM the user got an error when invoking the JIT. The permission does not allow the user to request JIT. When the user clicked the connect option from Azure portal VM UI, it was showing JIT was not enabled on this particular VM. Therefore, the connection was failing. But JIT was enabled on the VM, and a subscription owner/contributor were able to see “Request Access” when clicked Connect.

I learned that one option will be to use the reader role. But that would have given extra visibility to the VM that I was not interested in exposing.

The solution was to create a custom role at the VM level and assigned the external user to the role.

The permission needed are as follows:

If you prefer to use the JSON, you may use the following:

    "properties": {
        "roleName": "Just In Time (JIT) Request",
        "description": "Created by Clopez. Allow non-administrator to request JIT",
        "assignableScopes": [
        "permissions": [
                "actions": [
                "notActions": [],
                "dataActions": [],
                "notDataActions": []

The result was positive, and now the user has the options to request the JIT.

Azure Application Proxy – Step by step to setup an on-premises web application

Over the last months, and as we continue migrating our client’s on-premises infrastructure to the cloud, Azure Active Directory’s Application Proxy has become a very power tool used by organization looking into closing their VPN access, migrating workloads to the cloud, and reducing their on-premises footprint. While this is not the final solution for removing the on-premises services, it does serve as a steps to removing the relationship or need of VPN and connectivity to on-premises services, especially for organization that are transitioning from local AD to AzureAD-Joined devices. Azure application provides secure remote access to on-premises web applications. After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL or an internal application portal.

Licenses Requirements: With Azure Active Directory Premium P2 you can gain access to advanced security features, richer reports and rule based assignments to applications. Your end users will benefit from self-service capabilities and customized branding.

Azure AD Application Proxy is:

  • Simple to use. Users can access the on-premises applications the same way they access Microsoft 365 and other SaaS apps integrated with Azure AD.
  • Secure. On-premises applications can use Azure’s authorization controls and security analytics. Including Conditional Access and MFA. Also, Application Proxy doesn’t require you to open inbound connections through your firewall or VPN.
  • Cost-effective. To use Application Proxy, you don’t need to change the network infrastructure or install additional appliances in your on-premises environment.

Install and register a connector

To use Application Proxy, install a connector on each Windows server you’re using with the Application Proxy service.

To install the connector:

  1. Sign in to the Azure portal as an application administrator of the directory that uses Application Proxy.
  2. In left navigation panel, select Azure Active Directory.
  3. Under Manage, select Application proxy.
  4. Select Download connector service.
  • Read the Terms of Service. When you’re ready, select Accept terms & Download.
  • At the bottom of the window, select Run to install the connector. An install wizard opens.
  • Follow the instructions in the wizard to install the service. When you’re prompted to register the connector with the Application Proxy for your Azure AD tenant, provide your application administrator credentials.

Add an on-premises app to Azure AD

Now that you’ve prepared your environment and installed a connector, you’re ready to add on-premises applications to Azure AD.

  1. Sign in as an administrator in the Azure portal.
  2. In the left navigation panel, select Azure Active Directory.
  3. Select Enterprise applications, and then select New application.
  4. Select Add an on-premises application button which appears about halfway down the page in the On-premises applications section. Alternatively, you can select Create your own application at the top of the page and then select Configure Application Proxy for secure remote access to an on-premise application.
  5. In the Add your own on-premises application section, provide the following information about your application:
  6. Name: The name of the application that will appear on My Apps and in the Azure portal.
  7. Internal URL: The URL for accessing the application from inside your private network.
  8. External URL: The address for users to access the app from outside your network. If you don’t want to use the default Application Proxy domain, read about custom domains in Azure AD Application Proxy.
  9. Pre Authentication: How Application Proxy verifies users before giving them access to your application.
  10. Azure Active Directory: Application Proxy redirects users to sign in with Azure AD, which authenticates their permissions for the directory and application. I recommend keeping this option as the default so that you can take advantage of Azure AD security features like Conditional Access and Multi-Factor Authentication.

Connector Group: Connectors process the remote access to your application, and connector groups help you organize connectors and apps by region, network, or purpose. If you don’t have any connector groups created yet, your app is assigned to Default.

Best Practices for Azure Application Proxy

  1. Physically locate the connector server close to the application servers to optimize performance between the connector and the application.
  2. The connector server and the web applications servers should belong to the same Active Directory domain or span trusting domains.
  3. Install multiple connector servers on-premises to avoid a single point of failure.
  4. Configure FQDN and DNS records internally and do not use IP addresses.
  5. Make sure your connector servers have full internet access and can reach the Microsoft network.
  6. Use conditional access to secure access to your environment.
  7. Configure SSO to enhance the end-user experience