Hello, Community!
The June and July development update is here. Over the past two months, the VyOS team focused on security and compliance enhancements, community-driven improvements, platform updates, and customer engagement.
On the security side, we laid the groundwork for FIPS compliance, added post-quantum key exchange to IPsec, and started publishing SBOM artifacts for full supply-chain transparency. The community also stepped in with some hard-won fixes, from a zone-based firewall bug in VRF configurations to a route-target quirk that was causing needless traffic interruptions on every commit.
The network is the backbone of the IT infrastructure, and keeping it secure is one of the core requirements to protect everything else. VyOS has always taken this seriously, and now you can use some of the products of our commitment to security.
One of the core requirements for deployments in regulated environments and corporate networks where security is strictly policed is using products that provide adherence to established security frameworks and standards. One of the most well-known and most widely requested by users is FIPS. The process of certifying products for FIPS compliance is a long and bumpy road, but we are firmly on it, and you can already start using some of the building blocks now.
For example, you can flip a switch for OpenSSL and put it into FIPS mode. It is important to understand what this switch really does: it does not certify anything or make anything compliant - it restricts. With the switch enabled, OpenSSL is limited to the FIPS provider, and all algorithms, modes, and features that are not FIPS-compatible are excluded from use. Since OpenSSL is one of the core cryptographic libraries in the system and is used by a lot of services, this restriction automatically propagates to many of them, for example:
And a lot of components that are less externally visible. As you can see, the impact is significant. You may activate OpenSSL FIPS mode with a single command in the configuration:
set system option fipsIn future changes, more system components will be connected to this switch, and the same exclusion of non-FIPS-compatible cryptography will cover them automatically.
Pay attention - this switch is not FIPS compliance in any form, and you should not rely on it in places that must legally comply with FIPS. What it gives you is a system that refuses to use cryptography outside the FIPS-approved set - one of the first steps toward the full FIPS scope in future updates.
More details: https://vyos.dev/T8529
Cryptography does not stand still, and neither do we. IPsec in VyOS now offers post-quantum key exchange: ML-KEM algorithms (mlkem512, mlkem768, mlkem1024) can be selected in IKE and ESP group proposals, protecting your tunnels from "harvest now, decrypt later" attacks, where encrypted traffic is recorded today to be decrypted by quantum computers in the future. In addition to that, we added a CLI for Extended Sequence Numbers (ESN) in IKE and ESP group proposals with flexible negotiation - you can make ESN required, optional, or disabled, and VyOS will build proposals that interoperate correctly with both ESN-capable and non-ESN peers.
More details: https://vyos.dev/T8099, https://vyos.dev/T8097
Additionally, we have improved TPM-enabled encrypted configuration support with a small fix that prevents Cloud-init from breaking after encryption is activated in instances deployed with it. This is a minor change, but it makes using the feature in clouds more stable.
More details: https://vyos.dev/T8344
There are also other small fixes, like enabling code security scanning for more components in the system to catch issues before they even land in binaries.
You may also have spotted new artifacts in the latest rolling releases (https://github.com/vyos/vyos-nightly-build/releases/) - cdx.json and spdx.json files. For those of you who are already familiar with SBOM, they do not need any introduction, but for the rest of you, we would like to explain how these small additions may change your deployments and maintenance.
You may trust the vendor, but a flood of security incidents in past years, many of which involved third-party dependency poisoning techniques, should have put you on alert already. There are many actions that vendors take to protect customers from such problems, but there is also something customers may do as well - understand what risks they are exposed to and track these risks actively. This is where the Software Bill of Materials, or SBOM, steps in. This is the inventory list of a system or application, which answers the question of what components it consists of. This knowledge allows you to trigger actions on incoming security-related information, like new public vulnerability disclosures, even before a vendor issues a new security note or fix, as well as to perform a security and license analysis of the product before even launching it for the first time. The ecosystem of tools around SBOM is wide and well established - check it out if you have not used it yet; it opens wide opportunities for improving software management.
Being committed to full transparency for customers, we are now offering SBOMs for rolling images in two formats: CycloneDX (cdx.json) and SPDX (spdx.json).
We have supported the Salt automation framework for many years across multiple LTS versions, but as we noted in the blog last year (https://blog.vyos.io/vyos-project-november-2025-update), it was decided to remove the integration from the system due to an almost total lack of interest from customers. Now the action has been taken, and starting from 2026-06-10, new rolling builds do not have the feature anymore. If you need automation integrations, we recommend paying attention to our Ansible collection (https://github.com/vyos/vyos.vyos), which we actively maintain.
VyOS could not be built without our community, and here are some of the changes introduced by community members that we would like to highlight specifically: