DEV Community: puppet

Puppet Enterprise 2026.0, 2025.12.0, and 2023.8.12 Are Here

Gavin Patton — Mon, 19 Oct 2026 13:53:40 +0000

Puppet Enterprise (PE) 2026.0, 2025.12.0, and 2023.8.12 are now available.

PE 2026.0 highlights include: Puppet Core 9, new operating system support, patch management updates, security updates, and more.
PE 2025.12.0 moves to our latest-1 release, including critical security and bug fixes.
PE 2023.8.12 is now in extended support, which ends February 27, 2027. This release includes critical security and bug fixes.

What's New in Puppet Enterprise 2026.0

Built on Puppet Core 9

PE 2026.0 is the first Puppet Enterprise release built on Puppet Core 9. Puppet Core 9 updates key runtime and security foundations, including Ruby 4.0 and OpenSSL 3.5, and adds hardening for certificates, authentication, and server endpoints. Because you inherit these changes when you upgrade, we recommend testing your custom code and modules before rolling out.

Helpful resources:

Puppet Core 9 release notes
Puppet Core 9 upgrade documentation
Puppet Core platform support lifecycle
Validate your modules for Puppet Core 9 compatibility with Puppet Development Kit (PDK) 4.0

Patch Management Reporting

Patching tasks now report failures that occur while packages are being installed, instead of showing an overall success. Advanced Patching flags failed Windows patch runs as failures in the patch runs report, so your reports reflect what really happened.

Reliable CA Storage Migration and Recovery

PE 2026.0 uses database-backed CA storage by default. To make moving existing CA storage to the database, and recovering afterward, more dependable, this release includes several fixes:

Puppet runs no longer fail after cleanup
Missing on-disk CA files are handled
Mismatched backup restores are rejected up front
Fresh installs and imports are more reliable
Recovery no longer writes other nodes' settings into the primary

Security Refresh

PE 2026.0 includes many security updates, covering the Git tooling used by r10k, the nginx and Jetty web servers, FIPS cryptography, logging, and the toolchain used to build PE client tools. See Security Updates below, and Platform Support Updates for operating system changes.

What's Included in PE 2025.12.0 and PE 2023.8.12

PE 2025.12.0

This release moves PE 2025 into the latest-1 release. Highlights for the PE 2025 release include:

More reliable CA storage: Puppet runs no longer fail after a CA database-storage migration, and intentionally absent local CA files are handled correctly.
Security updates: See Security Updates below.

PE 2023.8.12 (LTS maintenance and security release)

This release includes security and bug fixes, including updated FIPS cryptography components, the Git tooling used by r10k, and related components. It does not add new features or change platform support.

Important for LTS customers: PE 2023.8.12 does not include the logging library (logback-core) fixes delivered in PE 2026.0 and 2025.12.0, which address CVE-2026-9828, CVE-2026-10532, and CVE-2026-13006. The 2023.8 line uses an older logging library branch that no longer receives upstream updates, so these fixes cannot be applied to it. Support for PE 2023.8.x ends February 27, 2027.

Platform Support Updates

Agent platform additions: AlmaLinux 10, Rocky Linux 10, Ubuntu 26.04 (AMD), and Ubuntu 26.04 (ARM)
Primary server platform additions: Ubuntu 26.04
Platform removals: Ubuntu 20.04 amd64 is removed for the primary server, and several older agent platforms are removed.
Manual installation: Debian 12 armhf requires manual installation.

Security Updates

All three releases include dependency updates that reduce your security exposure.

Release	Security updates
PE 2026.0	The broadest refresh: Git tooling used by r10k, nginx, Jetty, logging, FIPS cryptography, the toolchain used to build PE client tools, and many other components, including fixes for critical-severity vulnerabilities. Default PE deployments were assessed as not exploitable for the nginx vulnerabilities addressed.
PE 2025.12.0	Carries forward many of the same updates, including the Git tooling, nginx, Jetty, and client tools toolchain, plus additional dependency updates.
PE 2023.8.12	Updates the FIPS cryptography components (resolving ten vulnerabilities), the Git tooling used by r10k, and related components. Does not include the logging library fixes (see the note for LTS customers above).

For complete details, specific CVE identifiers, and component versions, see the release notes:

If you have questions about upgrading, contact Puppet Support or your account team.

Thank you for being a Puppet Enterprise customer.

The Puppet Enterprise Team

Smoke Study Video Review: A Practical Checklist for Pharmaceutical QA Teams

Modern Industry Insights — Tue, 13 Oct 2026 06:03:51 +0000

In pharmaceutical cleanrooms, airflow visualization helps teams understand how air moves around exposed products, critical surfaces, equipment, and operators during aseptic operations.

But recording a smoke study is only half the job.

The recorded footage must be reviewed to determine whether it provides sufficient evidence of airflow protection under the conditions defined in the approved protocol. This is where a structured Smoke Study Video Review becomes important.

For Quality Assurance (QA), validation, and engineering teams, the challenge is not simply identifying unusual smoke movement. It is determining what the observation means, whether it meets predefined acceptance criteria, and how the conclusion should be documented.

Here is a practical nine-point checklist for reviewing smoke study footage.

1. Verify the Study Configuration

Before interpreting the airflow, confirm that the video represents the approved study setup.

Check:

Protocol version and study identification.
Room and equipment configuration.
Smoke source and test conditions.
At-rest or in-operation state.
Relevant supporting airflow measurements.

If the recorded setup differs from the approved protocol, document the discrepancy and evaluate its impact before accepting the results.

This prevents reviewers from drawing conclusions from footage that does not represent the intended conditions.

2. Check Whether Critical Areas Are Visible

A video may contain extensive footage but still fail to demonstrate what matters.

Review whether the camera clearly captures the exposed product, critical surfaces, relevant equipment, and operator activities.

For example, if an operator's arm blocks the view of a filling point during an intervention, the reviewer may be unable to determine whether airflow protection was maintained.

Record the timestamp and location of any visibility gap. Then assess whether the available evidence is sufficient or whether supplementary footage or repeat testing is needed.

3. Evaluate First-Air Protection

First air is filtered air that reaches exposed product or critical surfaces before contacting other objects that could compromise its protective function.

During the review, follow the visible airflow path toward the critical zone.

Ask:

Does the airflow reach the exposed product as intended?
Do operator movements interfere with the airflow path?
Does equipment obstruct the intended air movement?
Is there evidence of a potential contamination risk?

EU GMP Annex 1 paragraphs 4.4 and 4.19 address protection of critical zones and first-air protection in relevant contexts.

An observation should be assessed against the approved protocol and supporting evidence rather than classified as a failure based on appearance alone.

4. Review Dynamic Operations and Operator Interventions

Airflow can behave differently when operators perform routine activities.

Examples include material replenishment, equipment adjustments, and interventions near critical processing areas.

Compare the recorded activities with the interventions defined in the approved protocol. Check whether the footage represents the intended operating conditions and whether important activities are missing.

EU GMP Annex 1 paragraph 8.16 addresses authorized lists of inherent and corrective interventions, taking their potential impact on airflow into account.

If a critical intervention was not recorded, document the gap and assess whether the study remains adequate for its intended purpose.

5. Interpret Turbulence and Reversal in Context

Smoke visualization may show eddies, turbulence, temporary reversals, or changes in airflow direction.

These observations are not automatically failures.

Their significance depends on factors such as:

Location of the disturbance.
Duration and frequency.
Proximity to exposed products.
Interaction with operator movements or equipment.
Evidence of maintained or restored protection.

For example, a temporary disturbance away from a critical surface may require a different assessment from airflow that visibly carries contamination from an operator toward an exposed product.

The review should document what was observed, evaluate the potential risk, and compare the evidence with the approved acceptance criteria.

6. Verify Coverage of Critical Locations

A review should confirm that all protocol-defined locations and scenarios are represented in the footage.

Depending on the facility, these may include filling points, exposed product pathways, equipment interfaces, and locations affected by interventions.

For barrier systems, EU GMP Annex 1 paragraph 4.20 addresses airflow pattern studies at relevant open-isolator interfaces and during RABS interventions, including door openings.

A simple location-by-location review can help identify missing evidence before the final report is approved.

7. Compare Findings with Predefined Acceptance Criteria

Once observations have been recorded, compare them with the approved acceptance criteria.

Avoid relying solely on subjective descriptions such as “good airflow” or “acceptable smoke movement.” The reviewer should explain how the evidence supports the conclusion required by the protocol.

Acceptance criteria should be established before reviewing the results. If they are inadequate, the issue should be addressed through the site's quality and change-control procedures rather than by adjusting criteria to fit the observed outcome.

Neither EU GMP Annex 1 nor the FDA's aseptic processing guidance provides a universal set of pass/fail thresholds for every smoke study video review.

8. Document Deviations and Follow-Up Actions

Unexpected airflow patterns, incomplete footage, or differences between the approved and actual setup may require investigation.

A useful review record should identify:

The observation and timestamp.
The affected location and operating activity.
The relevant acceptance criterion.
The potential impact on product protection.
The conclusion and required follow-up.

Where necessary, follow the site's deviation management process and determine whether corrective and preventive actions (CAPA) are appropriate.

If footage contains repeated takes or edited clips, retain the original recordings and document why the additional versions were created.

9. Maintain Video and Report Traceability

The final check is documentation integrity.

Verify that:

Video file identifiers match the report.
Timestamps correspond to the observation log.
Location labels are consistent.
Original recordings are retained alongside edited clips.
Deviations and follow-up actions are traceable.
Final conclusions match the approved protocol and acceptance criteria.

EU GMP Annex 1 paragraph 4.15 addresses the retention of airflow visualization recordings and documentation of outcomes.

Traceability allows another qualified reviewer to understand the evidence and follow the reasoning behind the final decision.

A Practical Example: Reviewing an Airflow Observation

Consider a hypothetical scenario in which smoke near an operator's forearm briefly moves toward an exposed product during a manual intervention.

The reviewer should not immediately classify the study as failed.

Instead, the review should establish:

Observation: Smoke movement toward the critical area.
Context: The intervention being performed and the location involved.
Evidence: The complete video sequence and relevant supporting data.
Assessment: Whether the movement compromises the protection required by the approved protocol.
Outcome: A documented conclusion and any necessary investigation or repeat testing.

This approach separates an observation from the decision made about it.

How EU GMP Annex 1 and FDA Guidance Fit Into the Review

EU GMP Annex 1 (2022), paragraph 4.15, addresses airflow visualization at rest and in operation, with video recordings retained and outcomes documented.

The FDA's guidance on sterile drug products produced by aseptic processing also discusses in situ airflow pattern analysis under dynamic conditions and documentation of conclusions.

These sources provide regulatory context for smoke study evaluation. However, the nine checks in this article are a practical review framework, not a verbatim regulatory checklist.

Facilities should define responsibilities, acceptance criteria, and documentation requirements through their approved protocols and quality systems.

Final Thoughts

A reliable Smoke Study Video Review requires more than watching smoke move through a cleanroom. It requires reviewers to connect the recorded evidence with the study protocol, operational conditions, contamination risks, and documented acceptance criteria.

For QA and validation teams, a structured checklist makes it easier to identify missing evidence, investigate potential concerns, and explain the final decision.

For a more detailed guide, see Smoke Study Video Review: 9 Essential Checks for QA Teams.

You can also explore IncepBio's cleanroom validation services for information about static and dynamic smoke studies in pharmaceutical manufacturing.

This article is intended for educational purposes. Study-specific decisions should follow applicable regulatory requirements, approved protocols, risk assessments, and site procedures.

SCE 2.3.0 for Windows improves auditing performance by 70%

Jason St-Cyr — Mon, 12 Oct 2026 11:50:00 +0000

Some underlying pieces have been completely rebuilt to really improve the performance of Security Compliance Enforcement (SCE) for Windows. This release also provides more detailed compliance reporting and simplifies ongoing maintenance using Puppet native modules.

SCE automates the enforcement of CIS Benchmark recommendations and DISA STIG guidance across Windows and Linux environments, helping teams maintain secure and compliant configurations at scale. SCE is available with Puppet Core and Puppet Enterprise Advanced.

Why Upgrade?

Improve performance and scalability by reducing policy enforcement overhead.
Gain more precise visibility into compliance changes.
Simplify compliance operations by identifying, validating, and remediating configuration drift more efficiently.

What's New?

Direct enforcement of Windows security and audit policies through Puppet native modules and Windows APIs, reducing reliance on third-party DSC content.
Per-setting reporting, with each CIS control mapped to its own resource in the Puppet catalog.

Security and Maintenance Updates

This release resolves an issue that could cause CIS compliance scans to incorrectly report AutoAdminLogon settings as non-compliant on Windows Server 2019 and 2022.

Next Steps

Read the release notes: SCE for Windows v2.3.0 release notes
Plan your upgrade to SCE for Windows v2.3.0 !

New to SCE?

If you haven't looked at SCE before and are wondering how you can use your existing Puppet management capabilities to expand into compliance auditing and enforcement, please explore the documentation to learn how SCE helps maintain secure configurations, thus protecting systems and data.

👀 Learn more about SCE

# OpenVox 9 ist da!

Martin Alfke — Fri, 09 Oct 2026 06:48:53 +0000

Am 2. Oktober 2026 hat die OpenVox-Project-Community das Release 9.0 von OpenVox veröffentlicht.
Damit basiert die Community-Version auf demselben Unterbau wie Puppet Core 9, das im August 2026 erschienen ist.

Der folgende Text ist eine Übersetzung mit kleineren Anpassungen vom Release Blog Posting.

Wir haben soeben OpenVox 9.0.0 veröffentlicht! Hierbei handelt es sich um eine Aktualisierung der Plattformbasis; das bedeutet, dass alle Kernabhängigkeiten auf aktiv gepflegte Versionen umgestellt wurden. Wer die jüngste Flut an CVE-Meldungen mit Sorge verfolgt hat, für den ist dieses Release genau das Richtige.

OpenVox 9 umfasst openvox-agent und openvoxdb in Version 9.0.0 sowie openvox-server in Version 9.0.1, ergänzt durch openfact 6.2.1.
(Das erste Release von openvox-server trägt die Nummer 9.0.1, da die Version 9.0.0 bereits durch ein Artefakt belegt war, das während der Beta-Phase versehentlich auf Clojars veröffentlicht worden war.)
Zudem wurde eine Reihe längst veralteter Code-Bestände entfernt.
Neue Funktionen sind für die Version 10.x geplant.

Release-Hinweise und Dokumentation

Die vollständigen Release-Hinweise, einschließlich Fehlerbehebungen und der Änderungen in den jeweiligen Vorabversionen, findet man hier:

openvox-agent: https://github.com/OpenVoxProject/openvox/releases/tag/9.0.0
openvox-server: https://github.com/OpenVoxProject/openvox-server/releases/tag/9.0.1
openvoxdb: https://github.com/OpenVoxProject/openvoxdb/releases/tag/9.0.0
openfact: https://github.com/OpenVoxProject/openfact/releases/tag/6.0.0 (OpenVox 9.0.0 enthält Version 6.2.1, die lediglich Fehlerbehebungen ergänzt)

Die Dokumentation zu OpenVox 9 findet man unter:

OpenVox: https://docs.openvoxproject.org/openvox/9.x/
OpenVox Server: https://docs.openvoxproject.org/openvox-server/9.x/
OpenVoxDB: https://docs.openvoxproject.org/openvoxdb/9.x/

OpenVox 9 beziehen

OpenVox-9-Pakete werden unter der Bezeichnung openvox9 bereitgestellt.
Um diese Repositories zu konfigurieren, muss das Paket openvox9-release installiert werden:

Pakete für macOS und Windows findet man unter:

Wenn Beta-Versionen oder Release-Candidates getestet wurden, gelanget man durch ein normales Paket-Upgrade zur finalen Version.
Vorabversionen enthielten eine Tilde in der Versionsnummer (z. B. 9.0.0~rc4), damit sie bei der Sortierung unterhalb der finalen Version eingeordnet wurden.

OpenVox 8 bleibt über die openvox8-Repositories verfügbar. Es wird weiterhin für mindestens sechs Monate wichtige Fehlerbehebungen und Sicherheits-Updates erhalten.
OpenVox-8-Agents können weiterhin mit OpenVox-9-Servern kommunizieren. Man muss nicht alles auf einmal umstellen.

Wichtigste Änderungen im Vergleich zu OpenVox 8

openvox-agent Ruby 4.0 (zuvor Ruby 3.2) und OpenSSL 3.5 LTS.
openvox-server verwendet JRuby 10.1, das mit Ruby 4.0 kompatibel ist. Dies ist ein Upgrade von JRuby 9.4, das mit Ruby 3.1 kompatibel war.
openvox-server und openvoxdb werden offiziell unter Java 21 und 25 unterstützt und getestet; die Unterstützung für Java 17 wurde eingestellt. Die Pakete laufen unter Java 25, sofern die Plattform dies bereitstellt, andernfalls unter Java 21. Die FIPS-Pakete laufen nur unter Java 21, da die Bouncy-Castle-FIPS-Bibliotheken nur bis Java 21 zertifiziert sind. Der Service nutzt jetzt den Paketpfad und nicht die Alternative (/usr/bin/java).
openvoxdb wird nun mit PostgreSQL 18 getestet.
openvox-agent enthält openfact 6; damit entfällt die Fact-Option ldapname, und es werden Warnungen zu künftigen Entfernungen (geplant für OpenVox 10) ausgegeben.

Vor dem Upgrade

Dies ist ein Major-Release mit Breaking Changes (Änderungen, die bestehende Konfigurationen oder Abläufe beeinträchtigen können).
Bitte die Release Notes vollständig durchlesen und die OpenVox 9.0.0 Release Notes beachten.

Die wichtigsten Informationen sind:

Der Standardwert für server ist nicht mehr puppet. Agents müssen server oder server_list konfigurieren oder SRV-Records verwenden (auch ca_server und report_server funktionieren für die jeweiligen Dienste). Ein Agent, der als Root ausgeführt wird, ohne dass eine dieser Optionen gesetzt ist, bricht mit einem Fehler ab.
Die Einstellung reports hat nun den Standardwert none anstelle von store. Setzen Sie reports = store auf Ihren Servern, wenn Sie darauf angewiesen sind, dass Berichte auf der Festplatte gespeichert werden.
Datenbindungen aus der Hiera-3-Ära sind entfallen. Die Einstellungen data_binding_terminus und environment_data_provider sowie der Hiera-3-Indirector-Terminus wurden entfernt; Hiera 5 ist der unterstützte Standard.
Java 21 ist nun erforderlich. Wenn die Dienste unter Java 17 starten, stürzen sie frühzeitig mit einer ClassNotFoundException für java.util.SequencedCollection ab.

Bekannte Probleme

Agent-Daemon kann gelegentlich beim Status „applying configuration“ hängen bleiben

Bei einer kleinen Anzahl von Nutzern wurde beobachtet, dass der puppet agent-Daemon keine Statusmeldungen mehr sendet, während ein per fork gestarteter Prozess mit der Bezeichnung puppet agent: applying configuration aktiv bleibt und sich nicht beendet (openvox#485).
Dies tritt selten auf: Die bisherigen Meldungen stammen von kleinen Linux-VMs mit nur einer vCPU, bei denen das Problem alle paar Tage auftrat.

Die Ursache ist eine seltene Race-Condition zwischen den Hintergrund-Threads für DNS-Auflösungen in Ruby (deren Verhalten sich in Ruby 3.3 und 3.4 geändert hat) und dem fork-Aufruf, der jeden Agent-Lauf einleitet.
Erfolgt der fork im ungünstigen Moment, übernimmt der Kindprozess eine gesperrte glibc-Resolver-Instanz (Mutex), wodurch jede Namensauflösung in diesem Kindprozess blockiert wird.
OpenVox 8 (Ruby 3.2) ist davon nicht betroffen.

OpenVox 9.0.0 enthält mehrere Änderungen, die die Wahrscheinlichkeit dieses Problems stark verringern und sicherstellen, dass sich der Daemon selbstständig erholt, sollte es dennoch auftreten:

Der Agent führt im Daemon keine Namensauflösungen mehr unmittelbar vor dem fork-Aufruf für einen Lauf durch (openvox#683); damit entfällt der in den Berichten identifizierte Auslöser.
Ein Lauf, der die Zeitvorgabe runtimeout überschreitet, wird nun beendet (abgebrochen), sodass der Daemon mit dem nächsten Lauf fortfahren kann (openvox#642, openvox#643).
openfact begrenzt die FQDN-Auflösung in seinen Hostname-Resolvern (openfact#177). Falls dieses Problem weiterhin auftritt, kann das Setzen von RUBY_TCP_NO_FAST_FALLBACK=1 in einer systemd-Override-Konfiguration für den puppet-Dienst die Häufigkeit des Auftretens verringern:

# systemctl edit puppet
[Service]
Environment=RUBY_TCP_NO_FAST_FALLBACK=1

Ein Neustart des puppet-Dienstes bereinigt keinen bereits hängengebliebenen Kindprozess; dieser muss mittels SIGKILL beendet werden.
Sollte das Problem bei Version 9.0.0 aufstoßen, bitte im Issue openvox#485 Informationen hinterlegen.

FIPS-Pakete enthalten ältere Bouncy-Castle-JAR-Dateien

Die FIPS-Builds von openvox-server und openvoxdb enthalten einen älteren Satz von Bouncy-Castle-FIPS-JAR-Dateien.
Die neueste Version der Bouncy-Castle-FIPS-1.x-Reihe weist ein kleines Problem auf, das in einer stark eingeschränkten Konfiguration (außerhalb der Standardeinstellungen) zu Schwierigkeiten führen könnte; daher führen wir kein Update auf diese Version durch.
Stattdessen wird OpenVox 9.1 auf die Bouncy-Castle-FIPS-2.x-Reihe umsteigen, welche für FIPS unter Java 21 vollständig zertifiziert ist.

Vielen Dank

OpenVox 9 würde ohne all jene nicht existieren, die Pull-Requests eingereicht, Fehler gemeldet, Vorabversionen getestet und an Diskussionen über anstehende Änderungen teilgenommen haben.
Vielen Dank an alle!

Ein besonderer Dank gilt den Personen, die in diesem Entwicklungszyklus einen Großteil der Arbeit geleistet haben, darunter unter anderem:

Tim Meusel für seine Arbeit an nahezu allen Repositories: Aktualisierungen von Laufzeitumgebungen und Abhängigkeiten, CI, Release-PRs sowie SBOMs.
Charlie Sharpsteen, für seine Arbeit an Server, Datenbank, Laufzeitumgebung und Build-Tools sowie für die umfassende Überarbeitung der Dokumentation („Great Docs Reset“).
Michael Harp, für den enormen Umfang an Dokumentationsarbeit – einschließlich der Unterlagen für Version 9.x – sowie für die Ermittlung der Ursache des oben beschriebenen Agenten-Hängers.
Nick Burgan, für den Ausbau der Release-Infrastruktur, Smoke-Tests sowie die Arbeit an der Paketierung für Java und FIPS.
Haroon Rafique, für die Pflege der Clojure-Komponenten von openvox-server und openvoxdb, FIPS-Korrekturen und mehr. Sichere Standardeinstellung für server.
Martin Alfke, für die Aktualisierung großer Teile der Dokumentation für OpenVox und OpenFact.
Robert Waffen, für die Neugestaltung der Container-Images und die Einführung von Multi-Plattform-Builds.
Ben Ford, für die „Getting-Started“- und „Quickstart“-Anleitungen, die Dokumentations-Tools sowie die Katalogvalidierung im Agenten.
Jerome Charaoui, für die Debian-Paketierung und Korrekturen zur Reproduzierbarkeit.
Josh Partlow, für die arm64-Unterstützung und weitere Arbeiten an den Abnahmetests.
Austin Blatt, für die Migration auf Jetty 12.
Chris Boot, für wochenlange, geduldige Debugging-Arbeit im Zusammenhang mit openvox#485.
Miranda Streeter, für die Verbesserungen der Startgeschwindigkeit der Container-Images.

Bei Fragen oder Problemen mit diesen Releases bitte im #openvox Channel auf Slack oder #voxpupuli-openvox im IRC melden.
Details findet man unter https://voxpupuli.org/connect/.

Puppetlabs Modules Roundup – September 2026

Jason St-Cyr — Tue, 06 Oct 2026 11:47:00 +0000

September 2026 saw 53 Puppetlabs modules get releases (some of which got multiple releases) in the Puppetlabs Forge catalog, so it is going to be a full edition of this month's roundup as I try to pull all of these changes into one place.

Across the month, the clearest themes were Puppet Core 9 support as it rolls out across nearly the whole catalog. This preparation also saw Puppet 7 support dropped in seven modules, so the summary below focuses on support changes, maintenance work, and operational impact.

Highlighted Updates

Puppet Core 9 support rolls out across nearly the whole catalog

Forty-nine of the fifty-three modules released this month shipped explicit Puppet Core 9 compatibility work. This included metadata bumps, new CI lanes, and in several cases a parallel Ruby 4.0 compatibility pass. The releases range from Tier 1 modules (examples: puppetdb, mysql, postgresql, stdlib, apache, firewall) to the full set of Bolt task-helper and cloud-inventory modules, making this the single largest coordinated update the puppetlabs namespace has shipped in one month in 2026. facts 1.8.0 is part of the same push, after first correcting an accidental major-version bump to 2.0.0 back down to a minor release.

Affected modules: accounts, acl, apache, apt, audit_policy, aws_inventory, azure_inventory, bash_task_helper, chocolatey, concat, docker, dsc_lite, facter_task, facts, firewall, gcloud_inventory, haproxy, http_request, iis, java_ks, kubernetes, motd, mysql, ntp, pkcs7, postgresql, powershell, powershell_task_helper, puppet_conf, puppetdb, pwshlib, python_task_helper, registry, ruby_plugin_helper, ruby_task_helper, sce_linux, scheduled_task, secure_env_vars, security_policy, sqlserver, sslcertificate, stdlib, terraform, tomcat, vault, vcsrepo, windows_env, wsus_client, yaml.

Puppet Core prep drops Puppet 7 support in seven modules

As part of preparing for Puppet Core, puppetdb, registry, acl, facter_task, puppet_conf, java_ks, and vcsrepo shipped new releases that drop Puppet 7 support outright. Because registry 6.0.0 was a major release and a breaking change, four of its dependents (chocolatey, wsus_client, windows_eventlog, and motd) had to widen their puppetlabs/registry dependency bound to allow the new major version.

Affected modules: acl, chocolatey, facter_task, java_ks, motd, puppet_conf, puppetdb, registry, vcsrepo, windows_eventlog, wsus_client.

Breaking changes to review

A small number of releases include compatibility-impacting changes that may need extra review in your modules or environments before rolling them out.

puppetdb: The new version 9.0.0 drops Puppet 7 support, changes the default postgres_version from 14 to 17 to match what Puppet Enterprise now installs, and adds strict Puppet data-type validation across module parameters that may reject previously-accepted invalid values.
registry: Version 6.0.0 drops Puppet 7 support as part of its Puppet Core update, a major-version change that required chocolatey, wsus_client, windows_eventlog, and motd to widen their dependency bounds to allow it. If your module is dependent on registry, you may want to look at updating your upper bound to allow it.

What Updates Happened to Puppetlabs Modules in September 2026?

The following is an alphabetical listing of modules which received updates in September 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

accounts 9.1.0

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11699) Add Puppet Core 9 support #515 (skyamgarp)

acl 6.0.0

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support and dropping support for Puppet 7.

(CAT-2360) Prepare module for Puppet Core / Drop Support for Puppet 7 #310 (david22swan)
MODULES-11712: Add Puppet Core 9 support #315 (span786)

apache 13.4.0

📅 Latest release: 2026-09-02 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11700) Add Puppet Core 9 support #2638 (imaqsood)

apt 11.4.0

📅 Latest release: 2026-09-09 (🌐 View on the Forge)

This release focused on adding support for Puppet Core 9.

(MODULES-11701) Add support for Puppet Core 9 #1275 (shubhamshinde360)

audit_policy 1.2.1

📅 Latest release: 2026-09-10 (🌐 View on the Forge)

This release fixed misleading ensure-change reports, added Puppet Core 9 support, and addressed some maintenance issues with the repo.

Includes monthly releases: 1.2.1 (2026-09-10), 1.2.0 (2026-09-08), 1.1.0 (2026-09-02).

[MODULES-11879] Fix misleading ensure-change reports when only flag differs #31 (mehul-jain1)
fix(MODULES-11932): Add Puppet Core 9 support in puppetlabs-audit_policy #28 (SugatD)
[MODULES-11839] Implement manifest init and add specs #26 (SugatD)
[MODULES-11794] Reformat CHANGELOG.md to Keep a Changelog format #24 (SugatD)

aws_inventory 0.9.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.9.0) while also adding support for Puppet Core 9.

Revert version bump from major to minor (1.0.0 -> 0.9.0) #33 (gavindidrichsen)
(BOLT-193) aws_inventory Pdk update to Puppet Core 9 #28 (gavindidrichsen)

azure_inventory 0.6.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.6.0) while also updating to Puppet Core 9.

Revert version bump from major to minor (1.0.0 -> 0.6.0) #21 (gavindidrichsen)
(BOLT-193) azure_inventory pdk update to Puppet Core 9 #18 (gavindidrichsen)

bash_task_helper 2.3.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (3.0.0 -> 2.3.0) while also adding the PDK update to Puppet Core 9.

Revert version bump from major to minor (3.0.0 -> 2.3.0) #40 (gavindidrichsen)
(BOLT-193) bash_task_helper pdk update to Puppet Core 9 #37 (gavindidrichsen)

chocolatey 9.1.0

📅 Latest release: 2026-09-10 (🌐 View on the Forge)

This release added Puppet Core 9 support and widened the puppetlabs/registry dependency to allow 6.x.

(MODULES-11731) Add Puppet Core 9 support #390 (shubhamshinde360)
(MODULES-11708) Widen puppetlabs/registry dependency to allow 6.x #392 (span786)

comply 3.9.1

📅 Latest release: 2026-09-01 (🌐 View on the Forge)

5 CVEs were addressed in this release. Check the official release notes for comply 3.9.1 for the full details.

complyadm 3.9.1

📅 Latest release: 2026-09-01 (🌐 View on the Forge)

5 CVEs were addressed in this release. Check the official release notes for complyadm 3.9.1 for the full details.

concat 10.1.0

📅 Latest release: 2026-09-03 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11714) Add Puppet Core 9 support #840 (amitkarsale)

docker 10.5.0

📅 Latest release: 2026-09-23 (🌐 View on the Forge)

This release added Puppet Core 9 support and fixed the EL7 Docker CE repository path to point at the correct CentOS source.

(MODULES-11718) Add Puppet Core 9 support in puppetlabs-docker #1065 (imaqsood)
(MODULES-11929) Point EL7 at the centos Docker CE repo path #1067 (imaqsood)

dsc_lite 5.1.0

📅 Latest release: 2026-09-08 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

Add Puppet Core 9 support #243 (LukasAud)

facter_task 3.0.0

📅 Latest release: 2026-09-15 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support and dropping support for Puppet 7, along with some CI maintenance.

(CAT-2372) Prepare module for Puppet Core / Drop Support for Puppet 7 #243 (SugatD)
(MODULES-11722) Add Puppet Core 9 support #246 (shubhamshinde360)
(CAT-2296) Update github runner image to ubuntu-24.04 #242 (shubhamshinde360)

facts 1.8.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (2.0.0 -> 1.8.0) while also adding Puppet Core 9 compatibility.

Revert version bump from major to minor (2.0.0 -> 1.8.0) #74 (gavindidrichsen)
(BOLT-193): facts pdk update for Puppet Core 9 compatibility #71 (gavindidrichsen)

firewall 8.6.0

📅 Latest release: 2026-09-02 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

MODULES-11717: Add Puppet Core 9 support #1302 (span786)

gcloud_inventory 0.4.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.4.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.4.0) #19 (gavindidrichsen)
(BOLT-193): gcloud_inventory pdk update to Puppet Core 9 #16 (gavindidrichsen)

haproxy 9.2.0

📅 Latest release: 2026-09-16 (🌐 View on the Forge)

This release added Puppet Core 9 support, introduced the haproxy::http_errors and haproxy::ring resource types, and added Ubuntu 24.04 support.

feat(MODULES-11716) Add Puppet Core 9 support #654 (imaqsood)
Add haproxy::http_errors and haproxy::ring resources #651 (UiP9AV6Y)
(CAT-2125) Add Ubuntu 24.04 support #620 (shubhamshinde360)

http_request 0.4.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.4.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.4.0) #24 (gavindidrichsen)
(BOLT-193): http_request pdk update to Puppet Core 9 #20 (gavindidrichsen)

iis 11.1.0

📅 Latest release: 2026-09-15 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11733) Add Puppet Core 9 support #420 (shubhamshinde360)

java_ks 6.1.0

📅 Latest release: 2026-09-23 (🌐 View on the Forge)

This month's releases made the keytool path configurable, dropped support for Puppet 7, and added Puppet Core 9 support. It also fixed incorrect boolean parameter handling and a Tempfile race condition.

Includes monthly releases: 6.1.0 (2026-09-23), 6.0.0 (2026-09-16).

Make keytool path configureable #477 (bastelfreak)
(CAT-2377) Prepare module for Puppet Core / Drop Support for Puppet 7 #471 (shubhamshinde360)
MODULES-11721: Add Puppet Core 9 support #475 (span786)
Fix boolean parameters #469 (alexjfisher)
Fix race condition by memoizing Tempfile objects #461 (alexjfisher)

kubernetes 8.2.0

📅 Latest release: 2026-09-24 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

MODULES-11735: Add Puppet Core 9 support #723 (span786)

motd 8.1.1

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This month's releases added Puppet Core 9 support and widened the puppetlabs/registry dependency to allow 6.x.

Includes monthly releases: 8.1.1 (2026-09-04), 8.1.0 (2026-09-02).

(MODULES-11708) Widen puppetlabs/registry dependency to allow 6.x #571 (span786)
(MODULES-11702) Add Puppet Core 9 support #561 (imaqsood)

mysql 17.3.0

📅 Latest release: 2026-09-28 (🌐 View on the Forge)

This month's releases added Puppet Core 9 support, support for hex hashes with the caching_sha2_password plugin, and a fix for the mysqld_version fact on FreeBSD. It also tightened validation on purge_conf_dir, fixed .my.cnf root password resolution timing, and allowed metacharacters in SQL file paths.

Includes monthly releases: 17.3.0 (2026-09-28), 17.2.0 (2026-09-16), 17.1.1 (2026-09-02).

Add ability to use hex hash with caching_sha2_password plugin #1612 (C24-AK)
Correct Fact mysqld_version on FreeBSD #1654 (kapouik)
feat(MODULES-11715) Add Puppet Core 9 support #1742 (imaqsood)
Restrict mysql::server::purge_conf_dir type to valid values (#1740) #1741 (jst-cyr)
Use deferrable_epp for .my.cnf to ensure root password resolve correctly #1698 (jiayuchen888)
Update conditional logic xtrabackup.pp to properly... #1609 (ndelic0)
allow metacharacters * and ? in sql file path #1544 (zivis)

ntp 11.2.0

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11705) Add Puppet Core 9 support #745 (skyamgarp)

peadm 3.38.3

📅 Latest release: 2026-09-15 (🌐 View on the Forge)

This month's releases completed the CA storage migration for split topologies, added support for PE 2023.8.11 and 2025.11.3, and surfaced provision_replica failures in the add_replica plan instead of hiding them.

Includes monthly releases: 3.38.3 (2026-09-15), 3.38.2 (2026-09-01).

Adding support for PE 2023.8.11 and 2025.11.3 #702 (Jade2153)
(PE-45431) Complete CA storage migration for split topologies #696 (Jade2153)
(PE-43490) Surface provision_replica failures in add_replica plan #677 (CharithaDunuwille)
(PE-45885) Add code-manager to the managed database list #698 (Magisus)
(PE-45110) Ruby 4.0 compatibility: fix missing default-gem deps, document upstream blockers maintenance #685 (CharithaDunuwille)
(PE-45390) Add code coverage reporting to CI #686 (seamymckenna)
Adding support for PE 2025.11.2 #694 (Jade2153)

pkcs7 0.2.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.2.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.2.0) #19 (gavindidrichsen)
(BOLT-193): pkcs7 pdk update to Puppet Core 9 #15 (gavindidrichsen)

postgresql 10.7.0

📅 Latest release: 2026-09-08 (🌐 View on the Forge)

This release added Puppet Core 9 support, allowed puppet/systemd 10.x, and fixed default_privileges idempotency on PostgreSQL 17.

(MODULES-11720) Add Puppet Core 9 support in puppetlabs-postgresql #1700 (imaqsood)
Allow puppet/systemd 10.x #1691 (deric)
(MODULES-11935) Fix default_privileges idempotency on PostgreSQL 17 #1701 (imaqsood)

powershell 6.2.0

📅 Latest release: 2026-09-09 (🌐 View on the Forge)

This release focused on adding support for Puppet Core 9.

(MODULES-11706) Add support for Puppet Core 9 #440 (shubhamshinde360)

powershell_task_helper 0.2.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.2.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.2.0) #10 (gavindidrichsen)
(BOLT-193) powershell_task_helper pdk update to Puppet Core 9 #7 (gavindidrichsen)

puppet_conf 3.0.0

📅 Latest release: 2026-09-02 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support and dropping support for Puppet 7.

(CAT-2387) Prepare module for Puppet Core / Drop Support for Puppet 7 #223 (SugatD)
(MODULES-11736) Add Puppet Core 9 support #225 (imaqsood)

puppetdb 9.0.0

📅 Latest release: 2026-09-30 (🌐 View on the Forge)

This release dropped Puppet 7 support, changed the default postgres_version from 14 to 17, and added strict data-type validation and Sensitive-type handling for secrets across module parameters, along with several other fixes.

Add strict Puppet data type validation across module parameters (String, Integer, Boolean, Enum, Array, Hash, Absolutepath, Stdlib::Host, etc.), including port validation restricted to the unprivileged range (1024-49151) #411 (chambersmp)
Support for Puppet Core 9
Breaking: Default postgres_version bumped from 14 to 17 to match the version installed by the latest Puppet Enterprise
Use the Sensitive data type for secrets (passwords) #331 (cocker-cc)
Extend the puppetdb_version fact to handle Debian packages #416 (rwaffen)
Updated to PDK 3.8.0, dropped Puppet 7 support, and tightened version requirements on module dependencies
Update CI workflows (maint) #410 (h0tw1r3)
Update CODEOWNERS #417 (chambersmp)
Correct spelling of "certificates" #414 (viscountstyx)
Lower the stdlib requirement back down, since puppetdb depends on puppetlabs/postgresql, which depends on puppet/systemd, and puppet/systemd does not yet support stdlib >= 10.0.0
Correct stale postgres_version documentation in puppetdb::init and puppetdb::database::postgresql that still referenced the old 11/9.6 defaults
Set open_ssl_port to default false instead of undef in unit test shared examples
Prepare module for Puppet Core 9 #438 (gavindidrichsen)
Feature maintenance #436 (klab-systems)
Update storeconfig ini section with masters #432 (XMol)
Issue 430: Fix Datatype for listen_addresses #431 (cocker-cc)
Only include 'firewall' module when necessary #415 (Geod24)

pwshlib 2.1.1

📅 Latest release: 2026-09-07 (🌐 View on the Forge)

This release declared Puppet Core 9 support in metadata.json and added a Ruby 4.0 / Puppet Core 9 CI lane, sourcing gems from Puppet Core.

Includes monthly releases: 2.1.1 (2026-09-07), 2.1.0 (2026-09-07).

Declare Puppet Core 9 support in metadata.json requirements #393 (LukasAud)
(CAT-2589) Add Ruby 4.0 / Puppet Core 9 lane, source gems from Puppet Core #385 (LukasAud)

python_task_helper 0.7.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.7.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.7.0) #25 (gavindidrichsen)
(BOLT-193): python_task_helper pdk update to Puppet Core 9 #22 (gavindidrichsen)

registry 6.0.0

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This release dropped Puppet 7 support, added Puppet Core 9 support, and added Sensitive data type support for registry_value.

(CAT-2389) Puppet Core update / Drop Puppet 7 support #315 (LukasAud)
MODULES-11708: Add Puppet Core 9 support #320 (span786)
(PA-8354): Add support for Sensitive data in registry_value #319 (span786)
Update link to Puppet modules contribution documentation #318 (jst-cyr)

ruby_plugin_helper 0.4.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.4.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.4.0) #13 (gavindidrichsen)
(BOLT-193) ruby_plugin_helper pdk update to Puppet Core 9 #10 (gavindidrichsen)

ruby_task_helper 1.1.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (2.0.0 -> 1.1.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (2.0.0 -> 1.1.0) #31 (gavindidrichsen)
(BOLT-193): ruby_task_helper pdk update to Puppet Core 9 #26 (gavindidrichsen)

sce_linux 2.9.0

📅 Latest release: 2026-09-09 (🌐 View on the Forge)

A few highlights from this release:

Crypto controls incorrectly configured on Rocky Linux 8. Crypto controls are intended to prevent the use of weak Message Authentication Code (MAC) algorithms. On Rocky Linux 8, the controls were not working as designed. The manage_crypto_policies block was updated to resolve the issue and enforce strong algorithms.
Error occurs when specifying active zone target for firewalld. Previously, an error occurred when users set an active zone target for the firewalld solution by specifying {"public"=>{"target"=>"DROP"}}. The "unable to parse" error was displayed because the {"public"=>{"target"=>"DROP"}} example shown on the Puppet Forge Reference page was invalid. To resolve the issue, the Reference page was updated to display only the valid example:.
PAM profiles not applied on Ubuntu Linux. Previously, pluggable authentication module (PAM) profiles were enabled but not applied, causing some 5.3.x controls to fail on nodes reported as compliant. The issue was resolved to ensure that the profiles are applied and the PAM stack is hardened.

Check the official release notes for sce_linux 2.9.0 for the full details.

scheduled_task 5.1.0

📅 Latest release: 2026-09-03 (🌐 View on the Forge)

This release focused on adding support for Puppet Core 9.

(MODULES-11734) Add support for Puppet Core 9 #277 (SugatD)

secure_env_vars 0.3.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.3.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.3.0) #8 (gavindidrichsen)
(BOLT-193): secure_env_vars pdk update to Puppet Core 9 #5 (gavindidrichsen)

security_policy 1.2.0

📅 Latest release: 2026-09-24 (🌐 View on the Forge)

This release added Puppet Core 9 support, isolated per-SID translation failures so one bad SID no longer fails the whole batch, and fixed the security_option provider missing out-of-band policy drift.

Includes monthly releases: 1.2.0 (2026-09-23), 1.1.2 (2026-09-18), 1.1.1 (2026-09-01).

[MODULES-11933] Add Puppet Core 9 support #57 (SugatD)
[MODULES-11947] Isolate per-SID translation failures from the whole batch #55 (mehul-jain1)
Fix security_option provider missing out-of-band security policy drift #50 (mehul-jain1)

sqlserver 5.2.0

📅 Latest release: 2026-09-02 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support, along with several CI and test-infrastructure fixes.

(MODULES-11725) Add Puppet Core 9 support in puppetlabs-sqlserver #511 (imaqsood)
(MODULES-11902) Force reinstall puppet_agent module in acceptance bootstrap #507 (SugatD)
(MODULES-11838) Update link to Puppet modules contributing documentation #504 (imaqsood)
(maint) Bump nightly ruby version to 3.2 #513 (imaqsood)
(maint) Bump actions/checkout from v3 to v4 #503 (imaqsood)
Release prep v5.1.1 #502 (github-actions)
Fix #464 #494 (InsanesTheName)

sslcertificate 6.1.0

📅 Latest release: 2026-09-02 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11726) Add Puppet Core 9 support #145 (imaqsood)

stdlib 10.1.0

📅 Latest release: 2026-09-07 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

(MODULES-11710) Add Puppet Core 9 support #1482 (skyamgarp)

terraform 0.8.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.8.0) while also adding Puppet Core 9 (Ruby 4) support.

Revert version bump from major to minor (1.0.0 -> 0.8.0) #46 (gavindidrichsen)
(BOLT-193) terraform pdk update to Puppet Core 9 (Ruby 4) #43 (gavindidrichsen)

tomcat 8.1.0

📅 Latest release: 2026-09-03 (🌐 View on the Forge)

This release focused on adding Puppet Core 9 support.

fix(MODULES-11727): Add Puppet Core 9 support in puppetlabs-tomcat #587 (SugatD)

vault 0.5.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.5.0) while also adding Puppet Core 9 support.

Fix metadata versionRevert version bump from major to minor (1.0.0 -> 0.5.0) #24 (gavindidrichsen)
(BOLT-193): vault pdk update to Puppet Core 9 #21 (gavindidrichsen)

vcsrepo 8.0.0

📅 Latest release: 2026-09-02 (🌐 View on the Forge)

This release dropped Puppet 7 support, added Puppet Core 9 support, and added support for Git sparse checkouts via Git includes.

(CAT-2397) Puppet Core upgrade / Drop Support for Puppet 7 #654 (LukasAud)
MODULES-11711: Add Puppet Core 9 support #659 (span786)
Enable Git Includes (Sparse Checkout) #637 (jplindquist)
(CAT-2296) Update github runner image to ubuntu-24.04 #652 (shubhamshinde360)
Configure Mend for GitHub.com #649 (mend-for-github-com)

windows_env 6.2.0

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This release focused on adding support for Puppet Core 9.

(MODULES-11728) Add support for Puppet Core 9 #117 (SugatD)

windows_eventlog 5.2.1

📅 Latest release: 2026-09-04 (🌐 View on the Forge)

This release widened the puppetlabs/registry dependency to allow 6.x and included some repo maintenance work.

(MODULES-11708) Widen puppetlabs/registry dependency to allow 6.x #103 (span786)
Configure Mend for GitHub.com #92 (mend-for-github-com)

wsus_client 6.4.0

📅 Latest release: 2026-09-09 (🌐 View on the Forge)

This release added Puppet Core 9 support and widened the puppetlabs/registry dependency to allow 6.x.

MODULES-11737: Add Puppet Core 9 support #240 (span786)
(MODULES-11708) Widen puppetlabs/registry dependency to allow 6.x #241 (span786)

yaml 0.3.0

📅 Latest release: 2026-09-11 (🌐 View on the Forge)

This release reverted the version bump from major to minor (1.0.0 -> 0.3.0) while also adding Puppet Core 9 support.

Revert version bump from major to minor (1.0.0 -> 0.3.0) #11 (gavindidrichsen)
(BOLT-193): yaml pdk update to Puppet Core 9 #8 (gavindidrichsen)

Until Next Time!

That wraps up the September 2026 roundup! If any of puppetdb, mysql intersect with your environment, the linked Forge pages and release notes are worth a closer look.

Feedback on the series is always useful, especially if there are module families or release-note patterns that deserve more attention in future editions.

More updates coming next month when the October 2026 releases land, after Hallowe'en.🎃
Have a great month!

🤖 AI Disclosure

This roundup is produced by a mostly-automated pipeline, with some AI sprinkled in for orchestration and enrichment (or 'Combobulating' and 'Finagling'), followed by a human review (that would be me) before publishing.

The automation is an open-source project with deterministic python scripts to crawl the Forge and determine which puppetlabs modules were released during a specific month (and catching when a module gets more than one release in a month). By combining a template, automation scripts, and some AI orchestration the content all gets pulled together for a structured markdown document. I then jump in to double-check the content and update any wording that seems repetitive or irrelevant (and sometimes I need to add some extra context that isn't in the changelog notes).

Where to get your vendors' SOC 2 reports (AWS, Vercel, Supabase, GitHub, Stripe and 25 more)

oded moshe — Wed, 30 Sep 2026 18:37:25 +0000

Your SOC 2 auditor will ask how you reviewed your vendors. Here is where 30 common startup vendors publish their SOC 2 report, who can download it, and what to check once you have it.

If you are preparing for SOC 2, sooner or later your auditor asks how you reviewed the vendors that touch customer data. The usual evidence is each vendor's own SOC 2 report, plus a short record of what you checked in it.

Getting the reports is fiddlier than it should be. Some live in a console, some behind a trust-center request form, and some only on certain plans. A few examples, each checked on the vendor's own pages:

AWS: download from AWS Artifact in the console, at no charge; an NDA acceptance applies.
Google Cloud / Google Workspace: Compliance Reports Manager, after signing in.
Vercel: request access through the Vercel Trust Center.
Supabase: Team and Enterprise plan customers download it from the organization dashboard.
GitHub: Enterprise Cloud owners, from the Compliance tab in enterprise settings.
Cloudflare: Super Administrators, from Compliance Documents in the dashboard, after a confidentiality statement.
Stripe: provided on request.

The full table of 30 vendors (Azure, Microsoft 365, Okta, Auth0, Datadog, Sentry, PagerDuty, OpenAI, Anthropic, MongoDB Atlas, Snowflake, Notion, Linear, Slack, HubSpot, Zoom, 1Password, Heroku, Netlify and more) is here, with links to each trust page:

https://policyseed.vercel.app/guides/vendor-soc-2-reports

Downloading the PDF is not the review

Read these six parts and write down what you found:

Type and period. A Type II covers a period of operation; a Type I is a single date. If the period ended long ago, ask for the newer report or a bridge letter.
Scope. Make sure the system description covers the product you actually use. Big vendors publish several reports.
The auditor's opinion. Unqualified is the expected result. A qualified opinion means a material problem: read which criterion and why.
Exceptions in the test results. A clean opinion can still come with individual deviations. Decide whether any affect how you use the vendor.
Complementary user entity controls. What the vendor expects you to do: enable MFA, manage your own users, configure encryption. Those become your controls.
Subservice organizations. The vendor's own vendors (often a cloud provider), usually carved out. Note them as fourth parties.

Record the date, the report period, the reviewer, any exceptions and your decision. That record, not the PDF, is what the auditor samples.

Keep it proportionate

A small company can easily use dozens of SaaS tools, and not all of them need a SOC 2 review. Tier vendors by the data they touch: the ones that store or process customer data get a full review with the report; tools with no customer data get a short documented check. Auditors look for a consistent rule applied to the whole inventory.

If you need the policy that sets those tiers and the review cadence, there is a free, editable Vendor and Third-Party Risk Management Policy template (Word or Markdown, no signup) at https://policyseed.vercel.app/policies/vendor-and-third-party-risk-policy. It is part of an open-source (Apache-2.0) set of 22 SOC 2 policies; I built it.

Cybersecurity Compliance for Developers: What "Audit-Ready" Really Means

Diginatives LLC — Mon, 28 Sep 2026 12:27:38 +0000

If you're a developer, the word "compliance" probably makes your shoulders tense. It sounds like paperwork, meetings, and someone asking you to screenshot a settings page at 5 p.m. on a Friday.

Fair. But here's the thing: cybersecurity compliance touches your code, your pipelines, and your access controls far more than it touches a spreadsheet. So it's worth understanding, especially when a customer asks, "Do you have a SOC 2 report?" and your manager turns to look at you.

Let's break it down without the fluff.

What compliance actually is

Compliance means proving, with evidence, that you follow a defined set of security practices. Note the word proving. Doing the right thing isn't enough; you need to show it.

Common frameworks you'll hear about:

SOC 2: common for SaaS companies; checks controls around security, availability, confidentiality, and more
ISO 27001: an international standard for running an information security management system
PCI DSS: required when you handle card payments
HIPAA: for healthcare data in the US
GDPR: personal data protection for people in the EU

Which one you need usually depends on your customers and your industry, not on your preference.

So what does "audit-ready" mean?

Being audit-ready means that if an auditor walked in tomorrow, you could show them what you do and prove you've been doing it consistently.

In practice, that boils down to a few habits:

Written policies that people actually follow. A policy nobody reads is decoration.
Access control. Who can reach production? Is it reviewed regularly? Do departed employees lose access the same day?
Change management. Pull requests, reviews, and approvals leave a trail. Auditors love trails.
Logging and monitoring. You can detect and investigate suspicious activity.
Risk assessments. You've identified what could go wrong and decided what to do about it.
Vendor management. You know which third parties touch your data.

Notice something? A lot of this is already sitting in Git, your cloud console, and your ticket tracker. The trick is collecting it neatly.

The developer-side checklist

Here's what tends to land on an engineering team's plate:

Enforce multi-factor authentication everywhere
Require code review before merging to main
Keep secrets out of repositories (use a vault or environment-based secrets manager)
Patch dependencies and track known vulnerabilities
Encrypt data in transit and at rest
Back up critical data and test restoring it
Keep infrastructure defined as code so changes are traceable

None of this is exotic. Most teams do half of it already, just informally.

Evidence is the boring, important part

Auditors don't take your word for it. They want samples: a list of employees with production access, a few merged pull requests with approvals, an example of a resolved security incident.

If you gather this once a year in a panic, it hurts. If you collect it continuously, say a monthly export of access reviews and a saved report from your vulnerability scanner, audit season becomes a non-event.

Small tip: name and date your files clearly. "access-review-2026-09.pdf" beats "final_v3_new.pdf" every time.

Type I vs Type II, quickly

For SOC 2, a Type I report says your controls were designed properly at one moment in time. A Type II report says they actually worked over a period, often several months. Customers usually trust Type II more, but Type I is a reasonable first step for young companies.

When to bring in outside help

Not every team has a security specialist. That's normal. Many companies hire external experts to run gap assessments, write policies, and guide them through the audit. If you're weighing that route, reading about cybersecurity compliance firms can help you understand what these partners typically offer before you start comparing them.

Others prefer to add temporary security engineers to their own team through staff augmentation, which keeps day-to-day control in-house while filling the skills gap.

Mistakes I see teams make

Treating compliance as a one-time project instead of an ongoing habit
Buying tools before understanding the requirements
Writing policies that describe how they wish things worked
Leaving engineers out of the conversation until the last minute

That last one is the big one. Bring developers in early and the controls fit your workflow. Bring them in late and everyone's annoyed.

Wrapping up

Compliance won't make you unhackable, and it isn't magic. What it does is force you to build consistent, documented, reviewable security habits, and that's valuable whether or not a customer demands a certificate.

Start small: pick one framework, list your current controls, and find the gaps. You'll likely be closer than you think.

What's been the most annoying part of compliance on your team? Drop it in the comments.

Nigerian Fintech Architecture — Six Functions CBN Will Ask About in the Sandbox Application

zikarelhub — Mon, 28 Sep 2026 08:26:23 +0000

There is one architectural diagnostic that separates CBN Sandbox-ready Nigerian fintech from products that appear ready but have critical gaps.

Can you name — precisely, with regulatory status — who performs each of these six functions in your product?

The Six Functions

const architectureDiagnostic = {
  kyc:                'Named provider + regulatory status + KYC tier satisfied',
  sanctionsScreening: 'Automated + onboarding AND ongoing + users AND counterparties',
  fxConversion:       'Named licensed entity — "Paystack" is NOT an FX licence',
  custody:            'Legally segregated — company bank account is NOT segregated custody',
  settlement:         'T+1 or T+2 — NOT the same as authorization',
  payout:             'Named executor + SLA + failed payout handling + reconciliation'
};

The Most Common Gaps

const commonGaps = [
  {
    gap: '"We use Paystack" as the FX answer',
    reality: 'Paystack is a CBN-licensed PSP. Not an FX licence holder.',
    fix: 'Named AFEX-licensed BDC, CBN-licensed IMTO or licensed fintech with FX permissions'
  },
  {
    gap: 'User funds in company bank account',
    reality: 'This is fund commingling — not segregated custody',
    fix: 'Trust/escrow account at licensed bank — separate from operational account'
  },
  {
    gap: 'Wallet credited on Paystack success',
    reality: 'That is authorization. Settlement is T+1 or T+2.',
    fix: 'Credit wallet only on confirmed settlement — not on charge.success webhook'
  },
  {
    gap: 'Sanctions screening at onboarding only',
    reality: 'Users must be screened on an ongoing basis',
    fix: 'Nightly screening job against UN, OFAC, NFIU, PEP lists'
  }
];

KYC — Named Provider Required

// Not "some verification service" — a named provider with named status
const kycSetup = {
  bvnVerification: 'NIBSS (Nigerian Inter-Bank Settlement System)',
  idVerification: 'Smile Identity / Youverify / Prembly',
  livenessDetection: '95%+ confidence required — defeats static photo attacks',
  sanctionsAndPEP: 'Included in most Nigerian KYC providers',

  // VASP track additional
  blockchainAnalytics: 'Chainalysis / Elliptic / TRM Labs — ALL incoming deposits'
};

Settlement State Machine — Required

// Authorization ≠ Settlement — model this explicitly
const STATES = {
  INITIATED:  'created — no money moved',
  AUTHORIZED: 'bank approved — NOT settled, NOT available',
  SETTLED:    'in Paystack balance — T+1 or T+2',
  AVAILABLE:  'credited to user wallet — ready for use'
};

// Available balance: only settled credits minus pending debits
const availableBalance = await ledger.query(`
  SELECT SUM(CASE
    WHEN entry_type = 'CREDIT' AND settlement_status = 'SETTLED' THEN amount
    WHEN entry_type = 'DEBIT' AND settlement_status IN ('PENDING','SETTLED') THEN -amount
    ELSE 0
  END) AS available
  FROM ledger_entries WHERE account_id = $userId
`);

The Corridor Map

// Required CBN Sandbox document
// Every entity, their regulatory status, data flows, fund flows, failure scenarios

const corridorMap = {
  entities: [
    { name: 'Your Platform', status: 'CBN Sandbox Applicant' },
    { name: 'NIBSS', status: 'CBN-regulated infrastructure' },
    { name: 'Smile Identity', status: 'Licensed KYC provider' },
    { name: 'Paystack', status: 'CBN-licensed PSP' },
    { name: 'Partner Bank', status: 'CBN-licensed commercial bank' }
  ],
  fundFlow: [
    'User → Paystack (AUTHORIZED)',
    'Paystack escrow → Paystack balance (SETTLED T+1)',
    'Paystack → Trust account at Partner Bank (AVAILABLE)',
    'Trust account → User wallet ledger (CREDITED)',
    'User wallet → Recipient via NIP (PAID OUT)'
  ],
  failureScenarios: [
    'Paystack settlement delayed — do not credit user wallet',
    'KYC provider down — queue and retry, do not onboard',
    'Sanctions match on existing user — suspend account, escalate'
  ]
};

ZikarelHub LTD is Nigeria's #1 software and digital agency — Nigerian fintech built with the architectural clarity CBN examination requires.

Which of the six functions does your product have the least clarity on right now? 👇

Building a Living Case Database: Schema, Human-in-the-Loop AI, and the Math That Kills Most Niche Sites

Hossam Saif — Thu, 24 Sep 2026 22:31:31 +0000

Most "build a niche site" posts stop at the content strategy.

This one starts where those posts usually end: the operating model.

I spent time reverse-engineering what it actually takes to run a site that publishes living case files instead of one-and-done articles. The full blueprint (architecture, data model, nine-prompt production pipeline, privacy gates, economics, and monetization) is here:

→ How to Build a True-Crime Case-Tracking Website From Scratch

What follows is the part I think is most useful for builders: the data and process decisions that determine whether the site survives past the first six months.

1. The core unit is not an article — it's a row

Every case is a structured record before it becomes a page. The schema is deliberately over-normalized from day one:

defendants, victims, attorneys, judge are foreign keys (or arrays of FKs), not free-text fields.
charges is its own table with per-charge legal status.
hearings is an append-only log (newest first).
last_verified is a first-class field that drives the stale-case metric.

Why? Converting flat text into linked entities later is one of the most painful refactors you can do on a live site. Plan for the graph even if the MVP UI still renders everything as plain text.

The page template is just a view over that schema:

Case Name / Docket
├── Status + Last Updated
├── Summary (2–3 sentences, rewritten as the case evolves)
├── Timeline (dated, newest first)
├── The Money / Harm
├── Key Documents
├── Related Cases
└── Update Log

2. The production system is nine prompts + one human gate

This is not an autonomous AI newsroom. It's a research and drafting pipeline with mandatory human sign-off on every legal-status claim, every newly named person, and every publication decision.

High-level flow:

Signal Hunter – monitors new filings, hearings, sealed-to-unsealed changes
Qualification – hard PASS/FAIL gates (primary source exists? trackable docket? privacy risk?)
Source Hunter + Claim Ledger – builds a citation table with claim ID, source, page/para, legal status, confidence
Analysis – patterns only if the ledger supports them; alternative explanations required
Entity Map – what lives on the permanent case page vs. what becomes a standalone explainer
Case File Builder – every factual sentence must cite a claim ID
Accuracy + Privacy Gate – the single most important step
Update Check – for already-tracked cases
Distribution

The privacy/accuracy gate is non-negotiable. Any open flag (minor identification, sealed records, presumption of guilt, secondary-only sources treated as fact) blocks publication.

3. The real constraint is operating capacity, not content ideas

Homicide Watch D.C. peaked at ~500k pageviews/month and still closed. The cost of keeping every active case current was effectively one full-time reporter. When the founders moved and couldn't find a local partner willing to fund that role, the site shut down.

That is the actual problem this architecture tries to solve.

Define these metrics before you publish the first case file:

Metric	Target	Warning
Active cases per editor	15–25	>30
High-activity cadence	Daily	>48h
Dormant cadence	Weekly	>14 days
Stale-case rate	<5%	>10%
Correction rate	<2 / 100	>5

Site health formula:

stale-case rate < 5% AND correction rate < 2 → the site is delivering what it promised.

stale-case rate > 10% → it has operationally collapsed, even if traffic looks great.

Size the number of active cases to what one person can actually sustain, not to what would be editorially interesting.

4. Why this is interesting for builders

Most AI content systems optimize for volume. This one optimizes for trust under continuous update pressure. The claim ledger, the hard privacy gate, and the explicit automation boundary (what AI can draft vs. what a human must sign) are the parts that make the difference between a site that can keep running and one that quietly dies when the founder gets busy.

If you're building anything that needs to stay accurate over time (case tracking, regulatory monitoring, product changelogs, research databases), the same pattern applies:

Structured schema first
Provenance on every claim
Explicit human gates on the high-risk decisions
Metrics that tell you when the operation is failing, not just when traffic is up

Full write-up with the complete prompt set, site map, monetization layers, and real-world examples (Homicide Watch, DC Witness, CourtWatch, etc.) is here:

https://www.moneytraces.com/2026/09/how-to-build-true-crime-case-tracking.html

Curious what others have found when trying to keep structured "living" data products accurate at low headcount. The operating numbers are the part most architecture posts skip.

Puppet Core 9.1 and 8.22 adds Debian 12 ARM V7L support

Jason St-Cyr — Tue, 22 Sep 2026 12:58:58 +0000

The latest releases of Puppet Core 9 and Puppet Core 8 are now available! Both releases contain the same types of changes, with minor differences in versions of components that were updated. The new Debian 12 ARM V7L is the only new addition this release while the focus of the changes are on security updates and a pair of compatibility fixes that address issues some users may have encountered in production environments.

If you're currently running Puppet Core 8.x or 9.x, this is a straightforward update worth planning for.

What Changed in Puppet Core 9.1.0 and Puppet Core 8.22.0

New agent platform: Debian 12 ARM V7L added as a supported agent platform.
Security updates: Several bundled components received updates to address recently disclosed vulnerabilities: OpenSSL, curl, libxml2, RubyGems, Ruby's resolv gem.
Compatibility fix for hiera-eyaml and Bouncy Castle
JSON dependency constraints updated to >=2.0, <4 to prevent compatibility issues with latest JSON releases.

Together these updates address more than a dozen published CVEs. If you track vulnerabilities internally, review the release notes for the complete CVE listing associated with your Puppet version.

Notes for Puppet 8 vs Puppet 9 Users

The customer-facing changes are effectively the same in both releases. There are a couple of implementation differences:

Puppet Core 8.22.0 updates OpenSSL 3.0.x, whereas 9.1.0 updates to OpenSSL 3.5.x
Puppet Core 8.22.0 ships hiera-eyaml 4.3.0, whereas Puppet Core 9.1.0 ships hiera-eyaml 5.0.1

The fixes and outcomes delivered by these updates are equivalent across both release tracks.

Full Release Notes

Before upgrading, make sure to review the release notes for your release track:

This update is a small one operationally but an important one from a security and maintenance perspective. Make sure to drop any questions you have about the release either here or in the Puppet community slack.

A New Beginning This Festive Season: The Aishwaryam Vision for Modern Homeownership

Sathish Sundaram — Tue, 22 Sep 2026 07:34:06 +0000

The festive season often brings a renewed focus on new beginnings. For many people, that can mean starting a new chapter in their personal lives, reassessing financial goals, or finally exploring the possibility of owning a home.

Link: https://www.aishwaryam.com/blog/aishwaryam-vision-festive-season-homeownership/

But modern homeownership is changing. Buyers are increasingly looking beyond the traditional idea of purchasing a house. Location, connectivity, amenities, construction quality, community, convenience and long-term lifestyle requirements are becoming important parts of the decision-making process.

This shift creates an opportunity to rethink what a new home should represent.

The Changing Meaning of Homeownership

A home is no longer evaluated only by its size or number of rooms. Today's buyers often consider how the property fits into their daily routine.

How long is the commute? Are essential services accessible? Does the neighbourhood support the family's lifestyle? Are the amenities genuinely useful? What will the ownership experience look like several years from now?

These questions are influencing how people research residential properties.

The result is a more informed approach to homeownership, where buyers compare the overall living experience rather than focusing exclusively on the property itself.

Why the Festive Season Can Be a Time for New Beginnings

The festive season traditionally represents renewal and fresh starts. From a homebuyer's perspective, it can also be a natural point to review long-term plans.

However, a festive season property investment should still be approached with the same level of due diligence as a property purchase at any other time.

Festive offers or limited-period incentives should not replace fundamental checks such as:

Project approvals and documentation
Location and connectivity
Construction quality
Developer track record
Total purchase and ownership costs
Possession timelines
Amenities and maintenance considerations
Suitability for the buyer's long-term needs

The occasion may create the motivation to explore a home, but research should guide the final decision.

What Does Modern Homeownership Look Like?

Modern homeownership increasingly revolves around convenience and adaptability.

A well-planned residential environment can bring together homes, amenities, open spaces and community-oriented features designed around everyday living.

For families considering a new home this festive season, the decision can therefore begin with a broader question:

What kind of everyday life do we want our home to support?

The answer can help narrow down choices based on location, configuration, amenities and budget.

The Aishwaryam Vision

The Aishwaryam vision focuses on creating residential environments that go beyond the basic definition of a house.

The approach places emphasis on contemporary living, thoughtful planning, quality and the relationship between homes and their surrounding environment.

For a real-estate developer, this means looking at homeownership from the resident's perspective—not simply as a transaction, but as part of a person's longer-term lifestyle.

That perspective is particularly relevant as homebuyers become more research-oriented and compare projects across multiple dimensions before making a purchase.

Technology Is Also Changing the Homebuying Journey

The way people discover and evaluate properties has changed significantly.

Buyers can now research projects online, compare locations, examine project information, watch walkthroughs, read reviews and investigate developers before scheduling a site visit.

Search engines, social platforms and AI-powered discovery tools are also becoming part of the research journey.

This makes transparency and accessible information increasingly important for real-estate brands.

A modern homeownership vision therefore extends beyond the physical project. It also includes how clearly a developer communicates information throughout the buyer journey.

A More Informed Festive-Season Decision

Buying a home is a significant financial and lifestyle decision. Festive campaigns can encourage people to begin their search, but the decision itself should be based on factors that remain relevant after the celebrations are over.

For buyers considering a new home this festive season, the process can begin with a simple checklist:

Define your needs → Research locations → Compare projects → Verify documentation → Evaluate costs → Visit shortlisted properties → Make an informed decision

A New Beginning, Thoughtfully Planned

The idea of a new beginning has always been closely connected with the festive season. In the context of homeownership, it can represent more than moving into a new address.

It can mean creating a space that supports family life, work, relationships, convenience and future aspirations.

As expectations around residential living continue to evolve, the future of homeownership will likely be shaped by a combination of thoughtful design, accessible information, technology and a deeper understanding of how people actually live.

For Aishwaryam, that is the larger idea behind its vision for modern homeownership: creating spaces where a new address can become the foundation for a new chapter.

CBN Regulatory Sandbox Cohort 2 — Technical Guide for Nigerian Fintech Builders

zikarelhub — Mon, 21 Sep 2026 11:10:27 +0000

The CBN has opened Regulatory Sandbox Cohort 2 to unlicensed Nigerian fintech startups for the first time. Here is the technical breakdown of what this means for Nigerian builders.

What the Sandbox Is and Is Not

const sandbox = {
  IS: 'Supervised testing with real users under CBN oversight',
  isNOT: 'A commercial licence or permission to scale',
  duration: '6-12 months',
  outcome: 'CBN readiness assessment for full licence application',
  cohort2Change: 'Unlicensed startups with working MVPs now eligible'
};

The Two Tracks

const tracks = {
  VASP: {
    for: ['Stablecoin settlement', 'Crypto on/off-ramps', 'Crypto wallets', 'Digital asset payments'],
    cbnChecks: ['AML/CFT for virtual assets', 'Blockchain analytics', 'Travel Rule', 'Cold storage custody'],
    additionalRegulator: 'SEC Nigeria — digital asset classification'
  },

  NON_VASP: {
    for: ['Open banking', 'Payment initiation', 'Fraud detection', 'Financial inclusion', 'RegTech'],
    cbnChecks: ['NDPA compliance', 'API security', 'Fraud controls', 'Complaints handling']
  },

  confirmWithCBN: ['Plain fiat remittance — not explicitly listed in either track']
};

Eligibility Check

function checkEligibility(startup) {
  const disqualifiers = [
    !startup.hasWorkingMVP && 'No MVP — concept stage not eligible',
    startup.hasOutstandingRegulatoryAction && 'Outstanding sanctions',
    !startup.hasInnovationBeyondExisting && 'No meaningful innovation'
  ].filter(Boolean);

  const missingCompliance = [
    'amlPolicy', 'sanctionsScreening', 'cdd',
    'consumerProtection', 'cybersecurity',
    'incidentResponse', 'dataProtection', 'namedComplianceOfficer'
  ].filter(item => !startup[item]);

  return {
    eligible: disqualifiers.length === 0,
    disqualifiers,
    complianceGaps: missingCompliance,
    readinessScore: Math.round(
      ((8 - missingCompliance.length) / 8) * 100
    )
  };
}

Don't Force a Track Fit

The most important advice for Nigerian fintech builders evaluating Cohort 2:

Do not add digital asset features just to qualify for the VASP track.

VASP adds: SEC Nigeria jurisdiction, blockchain analytics costs, Travel Rule infrastructure, custody architecture requirements and significant technical complexity. If your product is genuinely payments or open banking — the Non-VASP track is correct. The compliance overhead difference is substantial.

Tomorrow: The full readiness checklist — what CBN wants to see before you apply.

ZikarelHub LTD is Nigeria's #1 software and digital agency — CBN-ready fintech platforms built with compliance from the foundation.

Are you considering CBN Sandbox Cohort 2? Which track fits your product? 👇