AlmaLinux Cybersecurity: What Is Specific to AlmaLinux and Why It Matters

A great deal of AlmaLinux security coverage focuses on what it shares with RHEL: SELinux enforcing mode, firewalld, GPG-signed packages, OpenSCAP profiles. That coverage is accurate but incomplete. AlmaLinux has developed security properties that are genuinely specific to it -- things that do not exist in the same form in RHEL, Rocky Linux, or any other free enterprise Linux distribution. Some of these properties are advantages. Some introduce considerations that security teams need to understand before deployment. This guide covers the AlmaLinux-specific security landscape in full, without glossing over the nuances.

Supply Chain Transparency as an Active Security Control

Supply chain security has shifted from a niche concern to a front-page risk category. SolarWinds, XZ Utils, and a long list of similar incidents have demonstrated what happens when build pipelines are opaque: compromises go undetected for months, and when they are discovered, scoping the damage takes weeks because there is no forensic record of what was in the pipeline when.

AlmaLinux's response to this problem is architectural rather than procedural. Every package compiled by the AlmaLinux Build System (ALBS) has its SBOM data stored in Codenotary's immudb — a cryptographically chained, append-only immutable database that the AlmaLinux Foundation describes as tamper-resistant and positions as an open-source immutable-database standard deployed by large enterprises and government organizations. The security property that matters here is precise: no one, including AlmaLinux itself, can retroactively alter or delete an SBOM record once it has been written. This is not a policy guarantee backed by trust in a vendor's good intentions. It is an architectural one. Each record is cryptographically chained such that any modification produces a detectable inconsistency in the chain. The encryption key is client-side verified before every communication. The system is also designed to resist MITM attacks — immudb's tamper-evidence is active at the transport layer, not just at rest.

The AlmaLinux Foundation has developed a dedicated utility called alma-sbom that generates SBOM records in both CycloneDX and SPDX formats (JSON or XML) and allows administrators to verify that any installed package is notarized and trusted by querying the immudb instance with the package's build ID or RPM hash. Every package's build log is also publicly accessible in real time at build.almalinux.org -- anonymous, read-only, showing what is being built right now and complete historical build logs for every package.

The build pipeline itself enforces supply chain integrity at every stage. Each step of the AlmaLinux Build System -- from pulling sources from CentOS Stream git repositories through notarizing the git commit, authenticating the AlmaLinux source commit, building and authenticating the build artifact, signing the RPM, and finally uploading the signed package -- goes through Codenotary's Community Attestation Service (CAS) with a hash stored at every transition. If a build node attempts to consume an unsigned or unverified source, the system marks the build as having unverifiable sources rather than allowing it to proceed silently. This is meaningfully different from pipelines that authenticate inputs and outputs but not intermediate steps: it means a compromise at any single stage produces a detectable break in the chain rather than being laundered through subsequent stages.

No other free enterprise Linux distribution provides this combination: public, real-time build logs with anonymous access, plus per-package SBOMs stored in a cryptographically immutable database where AlmaLinux itself cannot retroactively alter records. This also satisfies the US Executive Order 14028 SBOM mandate and the EU Cyber Resilience Act Art. 13 requirements, so organizations running AlmaLinux can generate per-package provenance documentation as part of their standard compliance workflow rather than sourcing it separately. When AlmaLinux announced the CAS integration in October 2021, community manager Jack Aboutboul framed the decision in terms of the specific property that makes immudb structurally useful here, describing it as a "tamper-proof immudb database" -- a phrasing that differentiates it from conventional signed-SBOM approaches where the signature is verifiable but the record itself is stored in a mutable system. The CAS integration spans every stage from Git import through RPM signing, with each step producing its own CAS hash that is linked into a single chain-of-custody record.

A practically useful detail: the alma-sbom CLI accepts either a build ID (found in the AlmaLinux Build System UI) or the RPM package hash directly, and its output can be requested in SPDX-JSON, SPDX-YAML, CycloneDX-JSON, or CycloneDX-XML. For a full ISO, the alma-sbom iso --iso-image /path/to/isoimage subcommand produces an SPDX-JSON record covering every package shipped with that installer. For incident response work where you need to verify a specific installed RPM against the pipeline record, the --rpm-package argument takes the RPM file path itself and computes the hash inline, which is faster than extracting the hash from the Build System UI and pasting it in. Both the Git Updater step that pulls CentOS Stream sources and the manual notarization tool for corner-case sources that failed automatic notarization write back into the same immudb database, so the chain of custody is uniform regardless of how a given source arrived.

To verify a package's provenance yourself:

# Install pipx from EPEL, then install alma-sbom in an isolated environment
# (pipx avoids the --break-system-packages pattern and is the method
#  the AlmaLinux project documents in its SBOM user guide)
$ sudo dnf install -y epel-release && sudo dnf install -y pipx
$ pipx install git+https://github.com/AlmaLinux/alma-sbom.git

# Generate an SBOM for a package using its RPM CAS hash, CycloneDX JSON format
# The package subcommand takes --rpm-package-hash OR --rpm-package OR --build-id
$ alma-sbom --file-format cyclonedx-json \
    --output-file nginx-sbom.json \
    package --rpm-package-hash <sha256-of-rpm>

# Or point directly at a local RPM file -- alma-sbom computes the hash inline
$ alma-sbom --file-format spdx-json \
    --output-file kernel-sbom.json \
    package --rpm-package /path/to/kernel.rpm

# For a full ISO, use the iso subcommand -- produces a single SBOM covering
# every package on the installer image
$ alma-sbom --file-format spdx-json \
    --output-file almalinux-iso-sbom.json \
    iso --iso-image /path/to/AlmaLinux.iso

ABI Compatibility: The Security Tradeoff That Runs in Both Directions

In July 2023, AlmaLinux shifted from 1:1 binary compatibility with RHEL to ABI (Application Binary Interface) compatibility. The security implications of this shift run in two directions, and coverage tends to focus only on the positive one.

The security advantage

ABI compatibility freed AlmaLinux from structural dependency on Red Hat's release cycle. The first demonstration came almost immediately: AlmaLinux pushed its Zenbleed patches (CVE-2023-20593, a speculative execution bug in AMD Zen 2 processors that allowed unprivileged code to read data from other processes and the kernel) to the public repositories on July 27, 2023, ahead of RHEL's equivalent release. This was not a minor difference — Zenbleed had public proof-of-concept exploits available, and shipping first meant AlmaLinux systems were patched before RHEL systems in organizations that used both. The endoflife.date entry for AlmaLinux documents this as an accepted pattern: the community occasionally requests a security flaw be patched ahead of RHEL, and when the project complies, an announcement accompanies the out-of-cycle release — the patch is later reverted when the upstream delivers its own fix, avoiding long-term divergence. CVE-2024-1086 (a use-after-free in the Linux netfilter subsystem added to CISA's Known Exploited Vulnerabilities Catalog) is another example, which also drove a V2 re-validation of the FIPS kernel.

This capability has broader implications. AlmaLinux can backport security fixes from upstream kernels, apply patches from CentOS Stream before they reach a RHEL point release, and re-enable security features that Red Hat dropped for support-matrix reasons. The ABI model is structurally faster for security-critical fixes than 1:1 binary compatibility.

The security consideration

AlmaLinux now builds primarily from CentOS Stream sources rather than RHEL SRPMs. CentOS Stream sits upstream of RHEL -- it is the development preview for the next RHEL point release. This means there can be divergence in what packages contain versus what RHEL ships. In practice this has not caused widely reported security incidents, but it does have a practical implication for security teams: a security assessment that assumes AlmaLinux is byte-identical to RHEL is making an incorrect assumption since July 2023.

For ISV software support contracts and formal compliance documentation that explicitly names RHEL or a byte-identical RHEL rebuild, the ABI vs. 1:1 distinction has real consequences. Typical enterprise workloads -- web servers, databases, container orchestration -- see no practical difference. But if your compliance documentation literally says "RHEL" or if a vendor's support contract excludes non-byte-identical RHEL deployments, this distinction matters and should be investigated before deployment.

The Errata Advisory Taxonomy: A Security Tool That Goes Underused

One of the security capabilities AlmaLinux provides that CentOS never did is a fully classified, machine-readable errata system. CentOS famously did not ship updateinfo metadata, which meant tools like dnf update --security simply did not work. Every update had to be applied indiscriminately or tracked manually.

AlmaLinux's advisory system uses three prefixes that map to distinct operational responses:

• ALSA (AlmaLinux Security Advisory) -- security fixes corresponding to MITRE/NIST-assigned CVEs, ranked Critical, Important, Moderate, or Low
• ALBA (AlmaLinux Bug Advisory) -- bug fixes, which can include security-relevant corrections that do not have assigned CVEs
• ALEA (AlmaLinux Enhancement Advisory) -- enhancements and feature additions, generally not security-relevant

The operational security workflow this enables: a production environment can be configured to auto-apply only ALSA advisories rated Critical or Important while batching lower-severity updates for scheduled maintenance windows. This reduces patch exposure without triggering untested package changes during high-risk operational periods.

# List only Critical and Important security advisories for installed packages
$ sudo dnf updateinfo list --security --severity Critical
$ sudo dnf updateinfo list --security --severity Important

# Apply only security-critical updates (skips bug and enhancement advisories)
$ sudo dnf update --security

# Apply only Critical security updates -- the narrowest option
$ sudo dnf update --security --severity Critical

# Show full detail for a specific advisory including CVE IDs and CVSS scores
$ sudo dnf updateinfo info ALSA-2026:1690

# Configure dnf-automatic to apply only security updates automatically
$ sudo dnf install -y dnf-automatic
# Edit /etc/dnf/automatic.conf: set upgrade_type = security
$ sudo systemctl enable --now dnf-automatic.timer

AlmaLinux also publishes OVAL (Open Vulnerability and Assessment Language) streams for versions 8, 9, and 10. These machine-readable vulnerability definitions integrate with OpenSCAP, Nessus, Tenable Security Center, and similar tools, enabling automated CVE detection before and after patching. The AlmaLinux errata database is additionally indexed in Google's OSV (Open Source Vulnerabilities) database, meaning vulnerability correlation tooling that uses OSV will automatically include AlmaLinux package exposure data.

For organizations on TuxCare's Extended Security Updates or Endless Lifecycle Support, there is a separate set of machine-readable endpoints that is genuinely hard to find documented and is worth pinning into scanner configurations directly. The ESU OVAL stream for 9.2 lives at https://security.tuxcare.com/oval/els_os/almalinux9.2esu/oval.xml, with the 9.6 equivalent at https://security.tuxcare.com/oval/els_os/tuxcare9.6esu/oval.xml. For scanner vendors who have migrated to CSAF 2.0 -- which many have now that Red Hat deprecated CVRF on July 10, 2024 and is phasing out OVAL v2 -- TuxCare additionally publishes per-advisory CSAF at https://security.tuxcare.com/csaf/v2/els_os/almalinux9.2esu/advisories/ and per-CVE VEX documents at https://security.tuxcare.com/csaf/v2/els_os/almalinux9.2esu/vex/. The VEX documents are particularly useful because they carry explicit status labels (fixed, not_affected, under_investigation, affected) for CVEs that are investigated but not patched -- information that OVAL cannot express. For detection of whether a specific host is running ELS, the marker file is /etc/els-release; scanner profiles should test for its presence before consuming the ESU OVAL stream, since applying ESU OVAL to a non-ESU host will produce false-positive findings for advisories that are not applicable to the stock AlmaLinux package set.

FIPS 140-3: The Distinction That Compliance Documentation Routinely Gets Wrong

This is the area where the gap between what organizations believe is true and what is in fact true is largest, and where acting on a misunderstanding has direct compliance consequences.

Running fips-mode-setup --enable on a standard AlmaLinux installation does not give you FIPS 140-3 validated cryptography. What it does is restrict the system's crypto-policies framework to FIPS-approved algorithms -- enforcing cipher suite restrictions, disabling weak protocols, and constraining key length minimums. This is a useful hardening step. It is not FIPS 140-3 module validation.

The FIPS 140-3 validated packages are provided through TuxCare's Extended Security Updates product. TuxCare is a division of CloudLinux (the founding sponsor of AlmaLinux), and it covered the approximately $400,000 in NIST CMVP certification costs. The AlmaLinux Foundation has documented publicly that CloudLinux paid "nearly $400,000 in fees and costs" for AlmaLinux 9.2 to achieve FIPS compliance -- a figure that illustrates why no other RHEL-compatible distribution in the free/community tier has produced its own validated modules. The validated modules are:

• Kernel Crypto API -- CMVP certificate #4750 (AlmaLinux 9.2 kernel, first EL9-family kernel to receive FIPS 140-3 validation, with a V2 re-validation applied to include fixes for CVE-2024-1086 after it appeared on CISA's Known Exploited Vulnerabilities Catalog)
• OpenSSL -- CMVP certificate #4823
• GnuTLS, NSS, and Libgcrypt -- included in the validated package set

The AlmaLinux 9.2 kernel's Entropy Source Validation was also the first software implementation to receive a FIPS 140-3 ESV certificate using SHA3-256 as a conditioner, providing 256 bits of entropy compared to the previous 64-bit LFSR standard implementation. AlmaLinux 9.6 is advancing through the CMVP pipeline with all four modules (Kernel Crypto API, OpenSSL, GnuTLS, NSS) on NIST's "Modules in Process" list as of October 2025, with Libgcrypt already re-validated for 9.2 and retested under the 9.6 Operational Environment (making it the first Active 9.6 module). TuxCare has publicly stated its Extended Security Updates program aligns each validated version with up to five years of compliant patching with no certification gaps.

The magnitude of the CMVP processing bottleneck is worth internalizing when planning around validation timelines. AlmaLinux's Security Certification Manager Simon John, who led the 9.2 validation effort, has documented the process candidly in his write-up on the AlmaLinux blog: the CMVP review stage typically carries a queue in the range of six to eight months, which is why the "Modules in Process" list milestone carries near-certainty of eventual certificate issuance even though the final certificate can take close to a year to arrive afterward. This also explains why the 9.2 OpenSSL certificate (#4823) arrived weeks after the kernel certificate (#4750) despite being submitted at the same time -- NIST issues certificates sequentially as lab reports clear review, not in batches.

For organizations wanting to move to the validated package set on an existing AlmaLinux 9.2 installation, the install is deliberately minimal. TuxCare also publishes Community FIPS packages — free for non-commercial use — for both AlmaLinux 9.2 and 9.6, covering the validated kernel and OpenSSL (commercial deployments still need ESU for the full five-module set including GnuTLS, NSS, and Libgcrypt):

# Step 1: add the TuxCare FIPS community repository (same repo for 9.2 and 9.6)
$ sudo dnf -y install https://repo.tuxcare.com/fips/tuxcare-fips-release-latest-9.noarch.rpm

# Step 2a: on an AlmaLinux 9.2 base, install the 9.2 validated NVRs
# (the .tuxcare.N suffix distinguishes validated builds from the standard ones)
$ sudo dnf -y install openssl-3.0.7-20.el9_2.tuxcare.1 \
    kernel-5.14.0-284.11.1.el9_2.tuxcare.5

# Step 2b: on an AlmaLinux 9.6 base, install the 9.6 validated NVRs instead
# (TuxCare publishes current NVRs at docs.tuxcare.com -- verify before running,
#  NVRs are updated as validated patches are issued)
$ sudo dnf -y install openssl-3.2.2-6.el9_6.1.tuxcare.6 \
    kernel-5.14.0-570.21.1.el9_6.tuxcare.1

# Step 3: enable FIPS mode -- writes crypto-policies AND selects the FIPS kernel at next boot
$ sudo fips-mode-setup --enable

# Step 4: reboot so the FIPS kernel takes effect, then run the verification block below
$ sudo reboot

The distinction that catches organizations out on audit: after reboot, cat /proc/sys/crypto/fips_enabled returning 1 only tells you the kernel is running in FIPS mode. It does not tell you whether the running kernel is the CMVP-validated one. An auditor will ask for the exact kernel NVR (name-version-release) and cross-reference it against the CMVP certificate's Operational Environment definition. If uname -r returns something without .tuxcare. in the version string, you are running FIPS mode on an unvalidated kernel, which is not FIPS 140-3 compliance.

A practical scoping point that is easy to miss: FIPS validation is specific to both the module version and the Operational Environment. The CMVP certificate does not merely say "AlmaLinux kernel is validated" -- it says "this exact kernel build, running on this exact minor version of the OS, on these specific CPU architectures, is validated." Changing any of those variables breaks the validation boundary. This is why TuxCare pins FIPS-validated packages to specific minor versions -- 9.2, 9.6, and 9.10 are the planned validation milestones for AlmaLinux 9. Upgrading to a newer minor version outside those milestones would break FIPS validation continuity. TuxCare provides extended security updates for those pinned versions specifically to address this constraint, allowing organizations to receive CVE patches without being forced off their validated baseline. Each ESU release includes at least a one-year overlap with the previous one to give organizations time to plan validated upgrades.

# Confirm FIPS mode is active at the crypto-policies level
# Expected output: "FIPS mode is enabled."
$ fips-mode-setup --check

# Show the active system-wide crypto policy -- expected output: "FIPS"
$ update-crypto-policies --show

# Confirm the configured and generated policies are consistent
# Expected output: "The configured policy matches the generated policy"
# A mismatch here means crypto-policies was modified without running
# update-crypto-policies, which can silently break FIPS compliance
$ update-crypto-policies --check

# Confirm the running kernel is the TuxCare FIPS-validated kernel
# Expected: a kernel NVR containing ".tuxcare." (e.g. 5.14.0-570.21.1.el9_6.tuxcare.1)
# A kernel without .tuxcare. in its NVR is NOT the CMVP-validated module, regardless
# of what /proc/sys/crypto/fips_enabled says
$ uname -r

# Confirm the OpenSSL FIPS Provider is loaded and active -- this is the
# strongest single check: it proves that userspace crypto is coming from the
# validated OpenSSL FIPS Provider and not a fallback non-FIPS provider
$ openssl list -providers | grep -A3 fips

# The kernel crypto API FIPS flag -- a value of 1 means FIPS mode is
# engaged in the kernel, but this alone does NOT prove the kernel binary
# is the CMVP-validated one (the uname -r check above is what proves that)
$ cat /proc/sys/crypto/fips_enabled

DISA STIG: Official, Confusingly Named, and Often Misunderstood

In February 2025, DISA (the Defense Information Systems Agency) officially published a Security Technical Implementation Guide for AlmaLinux OS 9. It is the first RHEL clone to receive a version 9 DISA STIG, predating Oracle Linux 9's STIG (April--May 2025) and leaving Rocky Linux with no DISA STIG for any version as of early 2026.

The STIG's published name -- CloudLinux AlmaLinux OS 9 Security Technical Implementation Guide -- is a persistent source of confusion. "CloudLinux" appears because TuxCare (a CloudLinux division) submitted the STIG to DISA. Once DISA officially reviews, accepts, and publishes a STIG to the DoD Cyber Exchange at public.cyber.mil, it carries DISA's authority regardless of who submitted the underlying work. The STIG is genuinely official. You may encounter older sources describing it as "unofficial" or "TuxCare-maintained" -- that language predates the February 2025 official DISA publication and is no longer accurate. The NIST National Checklist Program entry at ncp.nist.gov/checklist/1264 records the full revision history, with original publication date December 17, 2024: V1R1 entered the NCP repository on December 17, 2024 and reached Final status on March 24, 2025; V1R2 was last modified April 9, 2025; V1R3 on September 2, 2025; V1R4 on December 5, 2025; V1R5 on January 23, 2026; and V1R6 — currently the Final revision on NIST NCP — was entered on April 10, 2026 and updated on April 15, 2026, available as the XCCDF 1.1.4 standalone download at checklist ID 1264. V1R5 contains 443 security controls based on NIST SP 800-53. When a new revision is published, procurement and scanning teams should pull the newest revision from DISA directly (U_CL_AlmaLinux_OS_9_V1R6_STIG.zip at the time of this writing), since rule wording, CCI mappings, and audit logic can change between revisions, but note that verified content-integrity hashes for the newer revision typically lag a few weeks behind initial publication as scanner vendors like Tenable update their audit catalogs.

The STIG's technical coverage is deep. STIG IDs in the ALMA-09- namespace address concurrent session limits (ALMA-09-001010), smart-card removal behavior (ALMA-09-002110), identity-file audit watches on /etc/sudoers, /etc/group, /etc/gshadow, /etc/passwd, /etc/shadow, and /etc/security/opasswd, and mandatory postfix package removal on systems without a legitimate mail relay requirement. Every rule carries a cross-referenced set of identifiers that map cleanly into other frameworks: for example, the audit-watch rule on /etc/group is STIG ID ALMA-09-005190, Vulnerability ID V-269131, severity CAT II (medium), mapped to SRG SRG-OS-000004-GPOS-00004 and satisfying additional SRGs covering account lifecycle events (SRG-OS-000037, SRG-OS-000042, SRG-OS-000062, SRG-OS-000239-241, SRG-OS-000303-304, SRG-OS-000392, SRG-OS-000462, SRG-OS-000466, SRG-OS-000470-471, SRG-OS-000476). That mapping matters because it lets auditors and ACAS/Tenable scanners correlate a single STIG finding against both the higher-level SRG and the specific CCI controls (CCI-000015, CCI-000018, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001403-001405, CCI-002130, CCI-002884) that ultimately trace back to NIST SP 800-53 control families AC-2, AC-17, AU-2, and AU-12 -- the actual control structure an AO cares about. The published V1R5 audit file itself is 1.06 MB, with MD5 0b2563b751a72a614d2190fcb04a9dcc and SHA256 1b38421ae90f07730dc7b70c2f01905d924dc84cbf159db91a62ee70e9a27bfd, both documented through Tenable's audit catalog so compliance teams can verify content integrity of files pulled through automation before running them against production systems.

On the practical value of having a STIG at all, TuxCare's Simon John — the Security Certifications Manager who led the AlmaLinux STIG and FIPS validation work — frames it in his technical write-up as "probably the highest level of security hardening guidance there is", a characterization that matches how it is typically used outside the DoD context by organizations mapping their controls to ISO 27001, PCI-DSS, or internal security baselines.

AlmaLinux also ships the SCAP Security Guide (SSG) in the base OS, providing CIS Level 1 and Level 2, DISA STIG-aligned, PCI-DSS, and HIPAA-relevant OpenSCAP profiles without any additional packages required. CIS additionally publishes official CIS Benchmarks for AlmaLinux OS 8, 9, and 10, including pre-hardened CIS Hardened Images. The combination -- DISA STIG, CIS Benchmarks, and OpenSCAP profiles all available in or alongside the base OS -- makes AlmaLinux's compliance scanning toolkit substantially richer than CentOS ever was.

# Install OpenSCAP scanner and SCAP Security Guide content
$ sudo dnf install -y openscap-scanner scap-security-guide

# List all available profiles in the AlmaLinux 9 data stream
$ oscap info /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml | grep "Profile"

# Run the DISA STIG-aligned profile scan and produce an HTML report
$ sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_stig \
    --results /tmp/stig-results.xml \
    --report /tmp/stig-report.html \
    /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

# CIS Level 1 Server scan (less restrictive, suitable for typical production servers)
$ sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
    --results /tmp/cis-l1-results.xml \
    --report /tmp/cis-l1-report.html \
    /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

Secure Boot Key Management: Air-Gapped by Design

AlmaLinux has supported UEFI Secure Boot since version 8.4, with its shim bootloader signed by Microsoft. What distinguishes AlmaLinux's approach is that the Foundation has publicly documented its key management process in the AlmaLinux wiki, and that process follows a more rigorous protocol than many commercial software vendors document publicly.

The key generation process: keys are generated on a machine that has never been and will never be connected to a network. The AlmaLinux wiki's procedure for key holders emphasizes repeatedly that the key generation machine must stay off the internet during the signing key file transfer. Keys are stored on FIPS 140-certified self-destructing USB hardware -- devices that physically destroy their contents if brute force or disassembly is attempted. The signing certificates are generated with efikeygen using a ten-year validity window (the maximum the shim bootloader accepts), and both CA and signing certificates are exported to PKCS#12 files that are then GPG-encrypted for offline distribution. Private keys are also imported into Yubikey PIV slots (slot 82 is used for the AlmaLinux signing chain) with non-default PIV PIN, PUK, and management keys set via ykman, and PIV retry limits increased to 9. Unlock codes for the hardware-encrypted drives are distributed separately through the Foundation's internal Vaultwarden password manager or via GPG-encrypted email, and key holders must store devices offline in fire-resistant safes or bank safety deposit boxes when not in active use.

The practical security relevance: when you verify Secure Boot on an AlmaLinux system, the chain of trust runs from the Microsoft UEFI CA through AlmaLinux Foundation certificates issued by Sectigo. The air-gapped key generation means that even if AlmaLinux's online infrastructure were compromised, the signing keys themselves would not be accessible to an attacker. The boot chain flows UEFI firmware -> shim (signed by Microsoft UEFI CA) -> GRUB2 (signed by the AlmaLinux signing certificate) -> kernel (signed by the AlmaLinux signing certificate) -> signed kernel modules, with an abort at any link that fails signature validation.

# Confirm Secure Boot is enabled (expected output: "SecureBoot enabled")
$ mokutil --sb-state

# List certificates currently trusted in the firmware DB
# The 2026 transition: you want to see both the 2011 AND 2023 Microsoft CAs
# for maximum forward compatibility. A system missing "Microsoft UEFI CA 2023"
# cannot verify new 2023-signed shim binaries without a firmware DB update.
$ sudo mokutil --db | grep -iE "microsoft|uefi"

# Check installed shim package version (for AlmaLinux 9.7+/10.1+ expect shim 16.1)
$ rpm -qa | grep -E "^shim-(x64|aa64)"

# Inspect the installed shim binary's signature chain
# On 2026+ x86_64 shim builds with dual-signing, pesign should report TWO signers
# (Microsoft Corporation UEFI CA 2011 AND Microsoft UEFI CA 2023)
$ sudo dnf install -y pesign
$ pesign -S -i /boot/efi/EFI/almalinux/shimx64.efi

# Alternative: sbverify from EPEL's sbsigntools lists signers in detail
# (EPEL is community-maintained, not vendor-supported, enable with awareness)
$ sudo dnf install -y epel-release && sudo dnf install -y sbsigntools
$ sbverify --list /boot/efi/EFI/almalinux/shimx64.efi

# Check SBAT revocation level -- important for detecting whether older,
# potentially vulnerable shim/grub binaries are still bootable on this machine
$ sudo mokutil --list-sbat-revocations

# List any MOK keys enrolled beyond the distro defaults (e.g. third-party
# driver signing keys). Anything unexpected here is worth investigating.
$ sudo mokutil --list-enrolled

SELinux Enforcing Mode: What the Default Really Prevents

AlmaLinux ships SELinux in enforcing mode by default, consistent with RHEL. Coverage of this typically stops at "SELinux enforcing is on." The specific security property it provides deserves more precision.

SELinux implements Mandatory Access Control (MAC) at the process level. A compromised process running as root within a confined SELinux context cannot access files outside its policy-defined domain, cannot bind to privileged ports outside its policy, and cannot load kernel modules unless the policy explicitly permits it. This constrains post-exploitation lateral movement in a way that traditional Unix permissions do not -- traditional permissions control what a user can access, but SELinux controls what a specific process can access even if that process is running as root.

The usual way organizations lose this protection is by setting SELinux to permissive mode because an application generates policy violations. Permissive mode logs violations without enforcing them. It provides zero access control protection while creating a false sense of security because the system appears to be using SELinux.

If that command returns Permissive rather than Enforcing, the system has no MAC protection. For any AlmaLinux deployment being audited or assessed, this is the first SELinux check. An entire class of post-exploitation techniques -- filesystem tampering, privilege escalation through confined services, lateral movement between applications -- require a writable, unconstrained filesystem and are structurally blocked by enforcing SELinux policies.

When applications conflict with SELinux policy, the correct remediation is to create a policy exception using audit2allow or semanage, not to disable enforcement. The ausearch and audit2allow workflow generates targeted policy modules that permit only what the specific application needs:

# Ensure audit2allow and semanage are available -- these ship in
# policycoreutils-python-utils and are NOT present on a minimal install by default
$ sudo dnf install -y policycoreutils-python-utils setools-console

# Check current SELinux mode -- must be Enforcing in production
$ getenforce

# Search the audit log for SELinux denials (AVC messages) from the recent past
# Use -ts today / -ts recent / -ts HH:MM to narrow the window as needed
$ sudo ausearch -m avc,user_avc,selinux_err -ts recent

# Generate a targeted policy module allowing only what was denied
# -M produces both the .te source file and the compiled .pp package
$ sudo ausearch -m avc,user_avc,selinux_err -ts recent | audit2allow -M myapp_policy

# CRITICAL: inspect the generated .te BEFORE loading -- audit2allow can grant
# more access than the app requires. A misgenerated policy that grants
# (for example) write access to a sensitive type weakens MAC silently.
# If anything looks broader than necessary, hand-edit the .te and recompile
# with: checkmodule -M -m -o myapp_policy.mod myapp_policy.te
#       semodule_package -o myapp_policy.pp -m myapp_policy.mod
$ cat myapp_policy.te

# Load the policy module -- applies immediately without reboot
$ sudo semodule -i myapp_policy.pp

# Verify the module is loaded
$ sudo semodule -l | grep myapp_policy

Post-Quantum Cryptography: What Is Active by Default and What Requires Configuration

AlmaLinux 10.1 ships OpenSSL 3.5 with support for the three NIST-finalized post-quantum algorithms: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) as a hash-based signature alternative. According to the AlmaLinux 10.1 release notes, the system-wide cryptographic policies "enable post-quantum cryptography (PQC) algorithms in all policies by default." This means TLS applications using OpenSSL will negotiate hybrid ML-KEM key exchange if both endpoints support it; older endpoints fall back to classical ECDH. The same release also introduces RPMv6 signatures, which allow multiple signatures per RPM package and support signing with PQC algorithms through Sequoia PGP tools (sq and sqv), providing a forward-compatible signing stack for the RPM supply chain.

The security case for deploying PQC now, before cryptographically relevant quantum computers exist, is the "harvest now, decrypt later" (HNDL) threat model. Nation-state adversaries are already collecting encrypted traffic in bulk with the intent to decrypt it retroactively once quantum computing capability matures. For data that must remain confidential for 10 to 15 years -- classified communications, long-term medical records, intellectual property, financial transaction records -- traffic encrypted today with classical RSA or ECDH could be decryptable within that window.

OpenSSH on AlmaLinux 10 supports the sntrup761x25519-sha512 hybrid key exchange, which combines NTRU Prime with X25519. This has been the default key exchange in recent OpenSSH versions. The hybrid approach provides forward secrecy against future quantum attacks while maintaining security against current classical attacks -- neither algorithm has to be trusted absolutely. If your organization is operating under NSA CNSA 2.0 guidance or preparing for FedRAMP post-quantum requirements, AlmaLinux 10.1 provides the cryptographic stack needed without sourcing packages from third-party repositories.

Implementation Details Even Seasoned Practitioners Miss

The AlmaLinux security architecture has depth that rarely surfaces in summary coverage. These are the specifics that come up in audits, incident response, and compliance reviews -- and that practitioners working with the distribution at a surface level often do not know.

The CMVP Operational Environment is narrower than it looks

Auditors looking at "AlmaLinux 9.2 kernel FIPS 140-3 validated" often assume the certificate covers AlmaLinux 9.2 running anywhere. The actual scope is narrower. The CMVP record for certificate #4750 specifies the tested Operational Environment as AlmaLinux 9.2 running on Amazon Web Services m5.metal instances with Intel Xeon Platinum 8259CL CPUs, tested in two variants: with PAA (Processor Algorithm Acceleration, covering AES-NI and related instructions) and without PAA. Certificate #4823 for the OpenSSL FIPS Provider carries the same OE scope. The certificates also cover aarch64 platforms under the same AlmaLinux 9.2 base, tested by atsec as the accredited CST lab.

The compliance consequence: running the validated kernel NVR on a materially different Operational Environment (a non-Intel CPU family, a hypervisor configuration the CMVP did not test, or hardware without the AES-NI extensions when the "with PAA" certificate is being claimed) puts the deployment outside the validation boundary. For high-assurance audits, the Operational Environment claim on the System Security Plan needs to match the CMVP certificate's OE list, not simply state "AlmaLinux 9.2."

The autopatch-tool pipeline is how AlmaLinux is built from CentOS Stream

AlmaLinux's transformation of CentOS Stream sources into AlmaLinux packages is not performed manually. The autopatch-tool is a YAML-driven pipeline (GPLv3, maintained by the AlmaLinux Foundation) that mechanically applies spec-file transformations: string replacements (RHEL -> AlmaLinux with optional count limits and regex support), line deletions, release-number suffix injection (the .alma postfix), changelog entry additions with author name and email, added source files or patches, and arbitrary pre-build scripts. Each per-package transformation lives as YAML at git.almalinux.org/autopatch/<package> with separate branches per major version (a8, a9, a10s). The security property that matters: every source-to-binary transformation is reproducible from committed YAML, so any reviewer can diff the autopatch rules for a given package against its upstream CentOS Stream source and see exactly what AlmaLinux changed. This is a substantially stronger audit property than "trust the builder."

The .alma release-field postfix is worth internalizing as an operational marker. If an RPM's Release field contains .alma, the package was rebuilt by AlmaLinux with modifications; if it does not, the package was rebuilt from CentOS Stream sources without branding or spec changes (the AlmaLinux FAQ notes that the rebranding only applies where text or visual displays say Red Hat, or where RHN license manager enforcements appear). A scanner looking at installed RPMs can distinguish rebranded packages from straight rebuilds just from the NVR, which is useful for license-audit and policy-compliance checks.

The ALBS immudb chain is finer-grained than "start and end"

Coverage of AlmaLinux's supply chain usually reports that the build pipeline has immudb records for build artifacts. The actual granularity is higher. The ALBS pipeline stages -- Git Service, Build Node, Test System, Sign Server, Release System, and the overarching Master Service -- each produce their own immudb hash as packages transition between them. Specifically documented in the AlmaLinux wiki: the Sign Server pulls unsigned packages, verifies they are notarized, signs them with the corresponding PGP key, then notarizes the signed artifact again and stores that second record in immudb before the signed package enters Artifact Storage. The same double-notarization pattern applies at every stage transition.

For incident response work, this means the scope of a supply chain compromise is bounded by whichever pipeline stage was compromised, not just "the build was or was not tampered with." If an incident responder is investigating a suspected package, the immudb record chain will show the exact stage at which the build either succeeded with correct notarization, succeeded with an unverifiable source (which ALBS flags rather than silently propagates), or failed. A CVE advisory that affects AlmaLinux-only code (autopatch-applied patches) can be traced to the specific Git commit through the Git Service's immudb record, not just inferred from the output RPM.

Secure Boot key protection uses HSM tokens from Certification Authorities

The air-gapped key generation procedure documented in the AlmaLinux wiki is the publicly-visible part of the key protection scheme. The shim-review submission for AlmaLinux on rhboot/shim-review adds a detail that rarely surfaces in downstream coverage: the signing keys are stored in FIPS 140-2 certified HSM tokens provided by the Certification Authorities that issue AlmaLinux's code-signing certificates. The Yubikey PIV slot (slot 82) with non-default PIN/PUK/management keys and extended retry limits is the day-to-day access mechanism, but the root signing keys live on CA-supplied HSMs. This is a materially stronger key-protection posture than software-only signing infrastructure.

SBAT revocation: non-obvious mechanics that affect incident response

Shim 15.6 and later use SBAT (UEFI Secure Boot Advanced Targeting) for revoking vulnerable bootloader, GRUB, and shim binaries without consuming dbx space. Three practical facts about SBAT that come up in incident response:

• SBAT revocations are unidirectional. Shim will never downgrade a revocation. Once the system has accepted a higher SBAT generation number, the only way to roll back to an older revocation level is to disable Secure Boot, boot the older shim to clear the revocation state, and then re-enable Secure Boot. This matters when recovering a system that bricked itself after a shim update revoked a bootloader still in active use.
• The opt-in mechanism is mokutil --set-sbat-policy latest. New shim builds include the latest-available revocation payload as opt-in data, not as automatically-applied. Running mokutil --set-sbat-policy latest and rebooting into the new shim applies that revocation payload. A shim build can also be compiled with -DSBAT_AUTOMATIC_DATE=YYYYMMDDCC to apply a specific revocation level automatically on first boot -- this is how distro vendors push hard revocations when a shim vulnerability is actively being exploited.
• Revocations can be delivered out-of-band via a revocations_sbat.efi binary without re-issuing a full shim. The rhboot/certwrapper repository produces these binaries, which must be signed by a certificate the installed shim trusts. This is the mechanism for pushing urgent SBAT updates between full shim rebuilds.

Operationally, an AlmaLinux fleet under centralized Secure Boot management should have a documented procedure for each of these paths before needing them during an incident.

IMA with signed-per-file package contents

Starting with AlmaLinux/RHEL 9, all package files are signed per-file through IMA, and the signatures are stored in the security.ima extended attribute on every installed file. This allows Integrity Measurement Architecture (IMA) Appraisal to verify individual files against their RPM-signed reference values without requiring administrators to generate and maintain golden-hash allowlists -- the reference values are already present on disk, signed by the packager key. On AlmaLinux 10, a signed sample IMA measurement policy ships at /usr/share/ima/policies/02-keylime-remote-attestation, designed for direct use with Keylime attestation. Copying it into /etc/ima/ima-policy with cp --preserve=xattr preserves the signature so systemd can load it at boot.

One observable consequence of per-file IMA signing: if a file is copied out of its installed location (for example, cp /usr/sbin/ip /tmp/), the security.ima xattr does not transfer by default, so IMA-Appraisal will refuse to execute the copied binary. This is a structural property that disrupts a class of post-exploitation techniques that rely on copying trusted binaries to writable locations for modification.

The Rust Keylime agent in AlmaLinux 10.2 uses a privilege-drop-and-verify pattern

AlmaLinux 10.2 follows the RHEL direction on Keylime's agent-driven attestation: the new Rust agent opens privileged resources at startup (IMA measurement logs at /sys/kernel/security/ima/ascii_runtime_measurements, UEFI event logs at /sys/kernel/security/tpm0/binary_bios_measurements) while still running as root, then irreversibly drops privileges to an unprivileged user. Following CERT C POS36-C guidelines, after calling setuid(), the agent verifies it cannot regain root by confirming setuid(0) fails. For the remainder of its lifetime, the agent operates unprivileged, accessing those security-sensitive files through file descriptors it opened before the privilege drop. This is a more defensive posture than the typical Python attestation agent that either stays root continuously or does not drop privileges at all.

The Rust agent also uses a push model: it acts as an HTTPS client toward a verifier endpoint rather than exposing inbound ports. No agent ports, no inbound firewall rules, no NAT traversal -- agents only need outbound HTTPS to a single verifier. This is operationally significant for attestation in segmented networks where agents cannot accept inbound connections from an attestation server.

Errata advisory IDs map to specific dates and CVEs through predictable URLs

AlmaLinux errata advisories follow a deterministic URL pattern at errata.almalinux.org: the path is /<major-version>/ALSA-YYYY-NNNN.html (for example, /9/ALSA-2026-1690.html). The year in the ID does not have to match the publication year for every advisory, but for the vast majority of errata it does. This lets automation directly construct an errata URL from a CVE-to-ALSA mapping without scraping. A simple script that needs to link installed packages to errata detail pages can construct the URL from the output of dnf updateinfo list --security and fetch the full JSON-LD-structured advisory page without any additional lookup.

Re-Enabled Drivers: The Attack Surface Tradeoff

AlmaLinux re-enables many device driver PCI IDs that Red Hat dropped from RHEL to optimize its support matrix. The drivers cover older storage controllers (Dell PERC via aacraid, HP Smart Array via hpsa, IBM ServeRAID, Adaptec, LSI MPT SAS via mpt3sas, Broadcom MegaRAID via megaraid_sas), Fibre Channel HBAs (QLogic qla2xxx and qla4xxx, Emulex lpfc), and network adapters (Mellanox Gen2 and ConnectX-2 via mlx4_core, Emulex BladeEngine via be2iscsi and be2net). This is a deliberate community service for organizations with constrained hardware refresh cycles -- government agencies, universities, industrial environments, and research facilities that cannot simply replace working hardware on a commercial vendor's deprecation schedule. The full enumerated list appears in the Extended hardware support section of each AlmaLinux release notes page.

The security tradeoff is real and worth stating explicitly. Red Hat's reason for dropping these drivers is not only support-matrix optimization -- it is also kernel attack surface reduction. Drivers that are not loaded cannot be exploited. Every loaded kernel module is potential attack surface: it must be trusted, it has kernel-level privileges, and any vulnerability in it is a kernel vulnerability.

If you are deploying AlmaLinux on modern hardware that does not require these legacy drivers, reviewing loaded modules and blacklisting unused ones is a meaningful hardening step:

# List all currently loaded kernel modules
$ lsmod | sort

# Check whether a specific AlmaLinux re-enabled driver is loaded
$ lsmod | grep -E "aacraid|be2net|be2iscsi|lpfc|megaraid_sas|mlx4_core|mpt3sas|mptsas|qla2xxx|qla4xxx"

# Blacklist a driver your hardware does not need (example: lpfc Fibre Channel HBA)
# Create a file in /etc/modprobe.d/ -- will take effect on next boot
$ echo "blacklist lpfc" | sudo tee /etc/modprobe.d/blacklist-unused-drivers.conf

# Rebuild initramfs to apply the blacklist immediately on next boot
$ sudo dracut --force

# Verify the module is no longer loaded after reboot
$ lsmod | grep lpfc

The risk profile of these drivers varies significantly. Drivers for widely deployed hardware from major vendors (HP, Dell, IBM) receive more community attention and are less likely to harbor undetected vulnerabilities than drivers for obscure or end-of-production hardware. A reasonable posture for security-sensitive environments: audit which of the re-enabled drivers are in use, blacklist those that are not, and document the exception for any that are loaded for active hardware.

Patch Lag Relative to RHEL: The Real-World Timeline

A recurring security operations question: how fast does AlmaLinux ship CVE patches after Red Hat? The answer varies by CVE severity and benefits from the ABI compatibility model.

For critical CVEs that Red Hat also patches quickly, AlmaLinux typically ships within hours to one business day of the upstream advisory. For the subset of CVEs where AlmaLinux can apply patches from CentOS Stream or directly from the kernel community ahead of a RHEL point release, it can ship faster than RHEL -- the Zenbleed example being the clearest documented case. For moderate and low severity CVEs, patches may accumulate and ship in batch minor release updates, creating a longer window than critical CVEs.

The practically useful security metric is not lag relative to RHEL but actual exposure window against your installed packages. The ALSA errata taxonomy gives you this directly:

This lists all security advisories that apply to packages currently installed on your system -- your actual exposure, not theoretical RHEL comparison. Combine it with --severity Critical to focus on the highest-priority items. For organizations that need deterministic patch SLAs, TuxCare's commercial support offering for AlmaLinux provides guaranteed patch timelines for High and Critical CVEs.

Details from the Primary Sources That Often Get Missed

Several technical details live only inside the actual CMVP Security Policy PDFs, the wiki, or the build-system repository. They have real operational consequences for experienced teams running AlmaLinux under compliance regimes, and they rarely show up in summary coverage.

The validated kernel module's cryptographic boundary is smaller than the kernel

The CMVP Security Policy for certificate #4750 defines the cryptographic boundary as specifically the kernel crypto object files, the libkcapi library (version 1.3.1-3.el9 as tested), the sha512hmac binary used for integrity verification, and the associated .hmac files that store expected integrity values. Anything outside that set -- any other kernel API that a userspace application might invoke -- is not part of the validated module, even on a system running a FIPS-validated kernel. An auditor evaluating FIPS compliance looks at which APIs the application crosses into, not just which kernel is booted. The tested kernel NVR is kernel-5.14.0-284.1101.el9_2.tuxcare.7 paired with libkcapi-1.3.1-3.el9, and that is the exact combination the validation covers.

AES-GCM key rotation is a post-reboot application responsibility

The OpenSSL FIPS Provider Security Policy for certificate #4823 documents a requirement that catches engineering teams by surprise during audits: if the module's power is lost and restored, the consuming application must ensure a new AES-GCM key is distributed before encryption or decryption resumes with that key. The module itself does not track power cycles and does not persist sensitive security parameters. An application that reuses an AES-GCM key across a reboot is technically operating outside the validated mode, even though nothing in the system will fail loudly. The same policy also states that the module supports importing externally-generated GCM IVs only in the non-approved mode -- importing an external IV for encryption in approved mode implicitly drops the module out of FIPS-compliant operation.

AES-XTS has a 16 MB per-instance data unit ceiling and a storage-only scope

Per the same OpenSSL FIPS Provider policy and CMVP Implementation Guidance C.I, the maximum length of data that can be encrypted or decrypted with a single AES-XTS instance is 2^20 AES blocks -- 16 MB. The module enforces the two-different-AES-keys check before any XTS cryptographic operation. The policy further restricts AES-XTS to the cryptographic protection of data on storage devices only; using XTS for data-in-transit encryption violates the validated usage even though the cipher will mathematically work. Full-disk encryption tooling such as LUKS calls into XTS correctly, but custom application-layer code that reaches for XTS as a general-purpose cipher is making an inaccurate compliance claim.

The installation-time versus post-install FIPS activation paths are documented separately

The Security Policy distinguishes between starting an installation in approved mode (adding fips=1 to the kernel command line during the installer, then avoiding any unsigned or untrusted third-party RPMs during software selection) and switching into approved mode after installation (running fips-mode-setup --enable and rebooting). Both paths produce a system running the validated module, but auditors reviewing documented installation procedures typically expect the former and may request additional evidence for the latter. For new builds intended for compliance workloads, the installation-time path reduces audit friction.

AlmaLinux's OSV feed is generated by a specific errata conversion tool

The AlmaLinux osv-database GitHub repository is compiled from AlmaLinux errata using a tool called errata2osv after each errata publication, and that repository is what osv.dev ingests. For scanners that consume OSV directly (rather than through osv.dev), the repository URL is the source of record and updates land there first. This also means that the OSV record for an AlmaLinux CVE is derived from the ALSA advisory, not from RHEL's CSAF VEX -- so OSV data for AlmaLinux will diverge from RHEL OSV data in the cases already described under the ABI compatibility model.

ELevate no longer supports Rocky Linux migrations as of November 2025

The ELevate migration project dropped Rocky Linux as a supported source or target on November 3, 2025, with the release of leapp-repository 0.23.0. The change came from two upstream factors: LEAPP gained native CentOS Stream and AlmaLinux support, and the migration-data format changed such that every supported OS required its migration data to be re-contributed under the new format. Rocky Linux contributors had not submitted the required migration data by the cutover, so Rocky Linux is no longer listed as a supported path. Organizations that were planning to use ELevate for Rocky-to-Rocky major-version upgrades, or Rocky-to-AlmaLinux conversions via ELevate, need a different migration path as of late 2025. Migrations to AlmaLinux from supported sources (CentOS 7, CentOS Stream, EL8, EL9) remain covered, and in-place upgrades from EL9 to AlmaLinux 10 are handled by the newer ELevate NG branch using the leapp-data-almalinux-x86_64_v2 data package.

KernelCare's Secure Boot integration avoids manual MOK enrollment

For organizations running AlmaLinux with Secure Boot enabled and deploying rebootless kernel patches through TuxCare's KernelCare, Agent 3.0-2 or later ships a Microsoft-signed helper binary that auto-injects the KernelCare signing certificate into the Secure Boot trust chain at boot, without requiring manual mokutil --import and the one-time MOK enrollment password ceremony. The helper is supported on RPM-based distributions (RHEL, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, CloudLinux, Amazon Linux) with UEFI boot, shim installed, and Secure Boot enabled. It is not available on Debian or Ubuntu. For air-gapped or policy-restricted environments where the MOK enrollment prompt is impractical to reach, this materially changes the deployment model for live kernel patching under Secure Boot.

Every AlmaLinux GPG signing key and its fingerprint

The AlmaLinux Foundation publishes the full key fingerprints on its security page, and pinning these into configuration management is more robust than relying on dnf's keyring import to fail loud. AlmaLinux OS 10 and Kitten 10 are signed with rsa4096/DEE5C11CC2A1E572 (issued 2024-07-11). AlmaLinux OS 9 uses rsa4096/D36CB86CB86B3716 (2022-01-18). AlmaLinux OS 8 uses rsa4096/2AE81E8ACED7258B (2023-10-10). The original 2021-01-12 key, rsa4096/488FCF7C3ABB34F8, is expired but still trusted for verifying already-signed legacy packages. ELevate migration packages are signed separately with rsa4096/429785E181B961A5 (2021-08-20). All keys live under /etc/pki/rpm-gpg/ on an installed system and are also downloadable from pgp.mit.edu.

The shim trusts two expired Foundation signing certificates for backward compatibility

Beyond the Microsoft UEFI CA chain, the AlmaLinux shim embeds trust for two AlmaLinux Foundation signing certificates whose signing validity has already expired -- Sectigo Public Code Signing CA EV R36 (expired January 30, 2025) and SSL.com EV Code Signing Intermediate CA RSA (expired January 19, 2025) -- plus the current active certificate. The expired certificates remain trusted for verification of binaries signed while they were valid, following the same pattern Microsoft uses for the 2011 CA after June 2026: expiration stops new signings but does not retroactively invalidate existing signatures. For AlmaLinux boot integrity verification tooling, this means the chain of trust depth for verifying an older installed kernel module may reach back into the expired Foundation certificates, and that is not a misconfiguration.

Immutable Infrastructure via the Atomic SIG

The AlmaLinux Atomic SIG, formed in 2025, is building bootc-based immutable desktop and server images. This represents a meaningful shift in security posture beyond traditional mutable OS deployments.

In an immutable OS model, the root filesystem is read-only during normal operation. Updates are applied by building a new OCI image layer and rebooting into it as an atomic transaction -- the entire root is replaced or rolled back as a unit. This defeats a class of persistence techniques that require a writable root: rootkits that modify system binaries, implants writing to /usr or /lib, and configuration tampering attacks. For threat hunters, the baseline drift problem that makes compromise detection difficult on mutable systems becomes structurally simpler: any deviation from the signed OCI image is detectable by comparing the running filesystem against the known-good image digest.

The Atomic SIG's images are published to quay.io/almalinuxorg/ and can be extended using standard OCI container tooling. Downstream distributions have already emerged -- HeliumOS, stillOS, and Querencia Linux. The EU OS proof-of-concept project exploring Linux for European government deployments listed AlmaLinux's immutable images as a candidate technology alongside Fedora Atomic spins. This is not yet widely deployed in enterprise AlmaLinux environments, but for use cases where immutability's security posture benefits justify the operational model change, the infrastructure is production-ready.

How to Assess and Harden an AlmaLinux Deployment for Security

Step 1: Verify SELinux enforcing mode and configure errata-based patching

Run getenforce and confirm the output is Enforcing. If it returns Permissive, the system has no MAC protection and returning it to enforcing mode is the highest-priority hardening action. Then run dnf updateinfo list --security to see all outstanding ALSA advisories against installed packages. Configure dnf-automatic with upgrade_type = security and apply_updates = yes for automated security-only patching.

Step 2: Verify SBOM provenance for critical packages

Install the alma-sbom utility from the AlmaLinux GitHub repository. Use it to pull CycloneDX or SPDX records for critical packages -- the kernel, OpenSSL, SSH server, any public-facing application packages -- and compare against the immudb-stored build records. Cross-reference build IDs at build.almalinux.org to verify the public build log matches your installed packages. Integrate this into your supply chain attestation documentation for EO 14028 or EU CRA compliance.

Step 3: Run OpenSCAP baseline assessment and remediate findings

Install openscap-scanner and scap-security-guide with dnf. Run oscap xccdf eval against the appropriate profile for your compliance requirement -- CIS L1 for general production servers, CIS L2 for higher-assurance environments, or the STIG profile for DoD-adjacent deployments -- using the correct data stream for your AlmaLinux version (ssg-almalinux9-ds.xml or ssg-almalinux10-ds.xml). Review the HTML report, prioritize high-severity findings, and remediate before production deployment.

Step 4: Determine FIPS requirements and install validated packages if needed

Determine whether your compliance framework requires FIPS 140-3 validated cryptographic modules. If yes, install TuxCare's Extended Security Updates package set rather than relying on fips-mode-setup --enable alone. Pin to the appropriate validated minor version for your AlmaLinux 9 deployment (9.2, 9.6, or 9.10). If your compliance documentation specifically requires FIPS 140-3 CMVP-validated modules, using the standard OS packages without TuxCare's validated set is not compliant.

Frequently Asked Questions

Does enabling FIPS mode on AlmaLinux give you FIPS 140-3 validated cryptography?

No. Running fips-mode-setup --enable on a standard AlmaLinux installation restricts algorithms to FIPS-approved ones via the crypto-policies framework, but the underlying cryptographic modules are not the CMVP-validated modules. FIPS 140-3 validated packages -- kernel CMVP certificate #4750, OpenSSL certificate #4823, plus GnuTLS, NSS, and Libgcrypt -- are provided exclusively through TuxCare's Extended Security Updates product. Organizations claiming FIPS 140-3 compliance for FedRAMP, DoD, or financial regulation purposes must install TuxCare's validated package set and pin those specific minor versions.

What makes AlmaLinux's supply chain security architecturally different from other enterprise Linux distributions?

AlmaLinux stores SBOM data for every package in Codenotary's immudb, a cryptographically chained, append-only database. No one, including AlmaLinux itself, can retroactively alter or delete a record once written -- the encryption key is client-side verified, and any modification produces a detectable inconsistency in the chain. Combined with public, real-time build logs at build.almalinux.org, this means supply chain provenance can be independently verified and, in the event of a compromise, the exact build timestamp of a tampered package can be established forensically. No other free enterprise Linux distribution provides this combination.

What are the security implications of AlmaLinux's ABI compatibility model versus 1:1 binary compatibility?

ABI compatibility allows AlmaLinux to ship security fixes ahead of Red Hat's release cycle -- demonstrated by the Zenbleed patches shipping before RHEL's equivalent in July 2023. The consideration running the other direction is that AlmaLinux builds primarily from CentOS Stream sources, which is upstream of RHEL, so there can be divergence from what RHEL ships. Security teams should query AlmaLinux's own ALSA errata rather than assuming RHEL advisories directly apply, and should use AlmaLinux OVAL streams rather than RHEL OVAL data for vulnerability scanning.

How does AlmaLinux handle post-quantum cryptography and is it enabled by default?

AlmaLinux 10.1 ships OpenSSL 3.5 with the NIST-finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) algorithms, and the system-wide crypto-policies framework enables PQC algorithms in all policies by default. TLS applications using OpenSSL will negotiate hybrid ML-KEM key exchange if both endpoints support it; older endpoints fall back to classical ECDH. OpenSSH supports the sntrup761x25519-sha512 hybrid key exchange. Organizations should verify that monitoring and SIEM tooling can parse PQC cipher suites, and that TLS inspection devices support hybrid key exchange.

What is the DISA STIG audit file content hash for AlmaLinux OS 9 V1R5, and why does it matter?

The DISA Cloud Linux AlmaLinux OS 9 STIG V1R5 (last modified on NIST NCP January 23, 2026) is a 1.06 MB audit file with MD5 0b2563b751a72a614d2190fcb04a9dcc and SHA256 1b38421ae90f07730dc7b70c2f01905d924dc84cbf159db91a62ee70e9a27bfd, containing 443 security controls. These hashes are publicly catalogued by Tenable and let compliance teams verify content integrity when pulling the file through automation, which is critical because a modified STIG audit file would silently skip or alter checks without an operator noticing. V1R6 is now the Final revision listed at NIST NCP checklist 1264 and should be used for new scans going forward, but verified content-integrity hashes for V1R6 typically lag a few weeks behind initial publication as scanner vendors update their audit catalogs. During that gap, V1R5 remains the latest revision with publicly cross-referenced hashes. The STIG IDs live in the ALMA-09- namespace (for example ALMA-09-005190 for the /etc/group audit watch, mapped to SRG-OS-000004-GPOS-00004 and Vulnerability ID V-269131), giving auditors a direct mapping into NIST SP 800-53 control identifiers.

What OVAL and CSAF endpoints does AlmaLinux publish for vulnerability scanning integration?

AlmaLinux publishes OVAL streams for versions 8, 9, and 10 through the Foundation, indexed in Google's OSV database and consumable by OpenSCAP, Nessus, Tenable Security Center, Qualys, and similar tools. For FIPS-validated and ESU deployments, TuxCare additionally publishes OVAL at security.tuxcare.com/oval/els_os/almalinux9.2esu/oval.xml and security.tuxcare.com/oval/els_os/tuxcare9.6esu/oval.xml, plus CSAF 2.0 advisories and per-CVE VEX documents at security.tuxcare.com/csaf/v2/els_os/almalinux9.2esu/advisories/ and /vex/. The CSAF/VEX endpoints matter because Red Hat deprecated CVRF in favor of CSAF VEX in July 2024 and is phasing out OVAL v2 -- vulnerability scanners that have migrated to CSAF need a CSAF source for AlmaLinux-specific advisories rather than falling back on RHEL data that no longer applies cleanly under the ABI compatibility model.

Sources and References

Technical details in this guide are drawn from official documentation and verified sources.

• AlmaLinux Security Measures -- GPG keys, Secure Boot certificates, errata, OVAL, and SBOM documentation
• AlmaLinux SBOM Information -- immudb storage architecture, CycloneDX/SPDX output, and supply chain attestation
• AlmaLinux Wiki -- SBOM User Guide -- alma-sbom utility usage, immudb query examples, and CycloneDX record format
• TuxCare -- FIPS 140-3 Validation and DISA STIG for AlmaLinux OS -- CMVP certificate details, validated module list, and DISA STIG development history
• NIST NCP -- CloudLinux AlmaLinux OS 9 STIG -- official NIST National Checklist Program entry confirming DISA publication status, original publication date December 17, 2024, V1R1 Final status March 24, 2025, currently at V1R6 Final
• AlmaLinux Wiki -- Secure Boot Key Generation and Handling -- air-gapped key generation protocol, FIPS-certified hardware storage requirements, and key distribution procedures
• AlmaLinux Shim 16.1 Update -- aarch64 transition to Microsoft UEFI CA 2023 key and x86_64 2011 key retention
• AlmaLinux 10.1 Release Notes -- PQC algorithm availability, crypto-policies defaults, and post-quantum OpenSSL 3.5 integration
• CIS Benchmarks -- AlmaLinux OS -- CIS Level 1 and Level 2 benchmark availability for AlmaLinux 8, 9, and 10
• AlmaLinux OS 10.0 Stable Release Announcement -- SPICE re-enablement, extended hardware driver re-enablement, x86-64-v2 support, and Secure Boot ARM64
• AlmaLinux Build System Wiki -- Codenotary SBOM Integration -- pipeline chain-of-custody architecture, CAS hash notarization at each build stage, and untrusted-source handling
• AlmaLinux alma-sbom Utility (GitHub) -- CLI reference for CycloneDX/SPDX output, JSON/XML/YAML formats, ISO-level SBOM generation, and the Git notarization tool
• AlmaLinux Wiki -- Errata Documentation -- ALSA, ALBA, ALEA advisory taxonomy and severity ranking
• TuxCare Documentation -- Machine-Readable Security Data (OVAL, CSAF) -- concrete URLs for ESU OVAL streams and CSAF VEX documents, plus the /etc/els-release detection marker
• TuxCare Enterprise Support for AlmaLinux Documentation -- CSAF advisory and VEX document endpoints for ESU 9.2 and 9.6, CVSSv3 severity methodology, and ESU coverage scope
• TuxCare -- AlmaLinux 9.6 FIPS 140-3 Certification Expands -- "Implementation Under Test" milestone status, overlap-based upgrade guarantees, and cost context
• TuxCare -- AlmaLinux 9.6 Modules in Process Milestone -- transition from IUT to MIP list, Libgcrypt re-validation for 9.2 under 9.6 OE
• AlmaLinux 9.2 FIPS Validation Update (October 2024) -- OpenSSL certificate #4823 issuance, TuxCare repository install commands, and cipher-suite verification examples
• Tenable Audit Catalog -- DISA Cloud Linux AlmaLinux OS 9 STIG V1R5 -- 443-control count, 1.06 MB file size, MD5 and SHA256 hashes for content integrity verification
• Codenotary immudb GitHub Repository -- append-only immutable database architecture, cryptographic coherence model, and Merkle tree consistency verification
• Codenotary CAS Launch Announcement (October 2021) -- original AlmaLinux-Codenotary partnership announcement and tamper-proof database positioning
• AlmaLinux Zenbleed Patch Announcement (July 2023) -- documented release date of July 27, 2023 for CVE-2023-20593 patches, shipped ahead of RHEL's equivalent
• endoflife.date -- AlmaLinux OS -- documented pattern of AlmaLinux occasionally patching ahead of RHEL when requested, and the project's revert-on-upstream-release policy to avoid divergence
• Red Hat Developer -- Secure Boot Certificate Changes in 2026 -- boot-continuity guidance applicable to AlmaLinux given the shared Microsoft UEFI signing chain, and RHEL 9.7 aarch64 2023-key signing confirmation
• NIST CMVP -- AlmaLinux 9.2 Kernel Crypto API Security Policy (Certificate #4750) -- validated cryptographic boundary definition, tested kernel NVR, libkcapi version, AES-GCM and AES-XTS usage constraints, and installation-mode guidance
• NIST CMVP -- AlmaLinux 9.2 OpenSSL FIPS Provider Security Policy (Certificate #4823) -- AES-GCM post-reboot key rotation requirement, AES-XTS storage-only scope and 16 MB data unit limit, PBKDF2 parameter ranges, and approved service list
• AlmaLinux osv-database GitHub Repository -- OSV feed compiled from AlmaLinux errata using errata2osv after each errata update, source repository for osv.dev ingestion
• AlmaLinux ELevate Project -- November 3, 2025 Rocky Linux support removal with leapp-repository 0.23.0, supported upgrade paths, and migration data format transition
• TuxCare KernelCare Live Patching Documentation -- Microsoft-signed Secure Boot helper binary for automated MOK enrollment (Agent 3.0-2+), supported RPM-based distributions, and live patch distribution architecture