# Validate Linux extension readiness across platform opt-in, guest mode, and agent version

> Is setting the Azure FIPS 140-3 extension-encryption flag sufficient to establish a working Linux extension path?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-559-validate-linux-extension-readiness-across-platform-opt-in-guest-mode-and-agent/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:22:37+00:00
- Modified: 2026-09-10T02:14:31+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Is setting the Azure FIPS 140-3 extension-encryption flag sufficient to establish a working Linux extension path?

## Potentially affected

Linux Azure VMs preparing for FIPS 140-3 extension-encryption support; this is a technical readiness check, not a compliance certification.

## DSE recommendation

Record platform opt-in, guest configuration, agent readiness, and protected-settings execution as separate acceptance checks.

## Article

## Source facts

Azure’s Linux FIPS 140-3 extension support requires per-VM platform opt-in as well as guest FIPS configuration and a compatible agent. Microsoft specifies Goal State Agent version 2.14.0.1 or later and validation of extension functionality. It warns against production opt-in on RHEL 9.5/9.6 with WALinuxAgent 2.7.0.6: after enablement and reboot, the agent can loop instead of becoming ready, preventing extensions from functioning. The documented RHEL workaround is for testing only. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/agent-linux-fips).

## Applicability

Use this technical readiness check for a Linux VM whose requirements call for the newer extension-encryption behavior. Inventory the actual distribution and both agent components before applying a platform flag. This article does not certify the workload or recommend using a test workaround in production.

## DSE recommendation

Record platform opt-in, guest configuration, agent readiness, and protected-settings execution as separate acceptance checks. Assign the guest configuration and extension tests to named operational owners. Hold a known affected RHEL/agent combination for a supported resolution rather than masking its readiness failure with the source’s test-only patch.

## Verification

On an approved test VM, inspect the platform property and guest configuration, then verify that the agent reaches Ready. Exercise a benign extension operation that actually uses protected settings and inspect its completion. Retain the exact versions and test result without including decrypted settings in the evidence. An enabled property alone should not close the investigation if the agent or extension path remains broken.

## Official references

[Microsoft Learn: Linux guest-agent and extension FIPS 140-3 support](https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/agent-linux-fips). Source reviewed September 9, 2026.

## Primary reference

- Name: FIPS 140-3 Support for Azure Linux VM Extensions and Guest Agent - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/agent-linux-fips
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Validate Linux extension readiness across platform opt-in, guest mode, and agent version,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-559-validate-linux-extension-readiness-across-platform-opt-in-guest-mode-and-agent/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.