A product composed of twelve services, three different base images, and two vendor-purchased components easily produces twenty or thirty SBOM documents for each release. The Cyber Resilience Act¹, however, asks for one: the unit of evidence is the product placed on the market, not the repository nor the single build.

It is the gap between how pipelines work and how the regulator thinks. SBOM generation is a solved problem: Syft², Trivy³, and registry-integrated scanners produce CycloneDX or SPDX in a few seconds. What is missing, in most setups we have seen, is composition: an authoritative document per product version that holds together component SBOMs without flattening them into a monolithic file. This article addresses that problem: how to link, sign, and maintain over time a product bill of materials in multi-service architectures.

Why do SBOMs multiply in a multi-service product?

Multiplication is not a configuration flaw: it is a structural property of cloud-native architectures. It operates along three axes that combine by multiplication, not addition:

1. Services and repositories: each service with its own release cycle generates its own documents, and each monorepo with multiple publishable artifacts behaves as N distinct sources.
2. Type along the lifecycle: CISA taxonomy⁴ distinguishes Design, Source, Build, Analyzed, Deployed, and Runtime SBOMs. These are different views of the same software, not copies.
3. Origin of components: first-party code, base images with their OS packages, language runtimes, firmware, third-party components delivered by vendors.

A Source SBOM and a Build SBOM for the same service are not redundant. The former describes what is declared in manifests and lock-files; the latter describes what actually entered the shipped artifact. Generating only from source yields both false positives (declared dependencies that are never compiled) and blind spots: system libraries in the base image, static binaries linked during build, vendorized modules. The first case inflates triage, while the second makes it incomplete right where risk is most opaque.

The recurring failure mode has a recognizable shape. Folders of CI artifacts with limited retention, a spreadsheet tracking which merge is the most recent, no document that anyone is willing to declare authoritative for the release on the market. This SBOM sprawl carries a cost that manifests at the exact worst moment: upon the appearance of an actively exploited vulnerability, the team does not answer the question “which product version contains the affected component and in which service”, but the much poorer question “where is the right file”.

The probability of that question arising is not remote. The 2024 OSSRA report shows 91% of examined repositories containing components that are ten versions or more behind⁵: in a product with ten services, the presence of at least one outdated and potentially affected component is the normal condition, not the exception. Granular visibility into dependencies is the prerequisite for everything else, a point we already covered when analyzing how the Software Bill of Materials makes third-party risks traceable under the CRA.

Technically, the regulation asks for four things, and it is best to read them as specifications. The SBOM must be machine-readable: JSON or XML in CycloneDX or SPDX format⁶, whereas a PDF attached to documentation does not satisfy the obligation. The common format is not prescribed. The legal minimum, set by Annex I, Part II of the CRA, is first-level dependencies, but in cloud native, transitive dependencies are the core of the risk, making the legal minimum a floor, not a goal. Above all: a representation of dependency and containment relationships is required, not a flat list of names.

The SBOM is part of the technical documentation defined in Annex VII of the CRA¹: it is not proactively transmitted, but must exist when placed on the market and be producible upon reasoned request from a market surveillance authority. Deadlines set the context: September 11, 2026 for vulnerability reporting obligations, December 11, 2027 for full application.

Compose or merge: which strategy holds up in a product audit?

Both approaches are compliant. The CRA does not impose an aggregation mechanism; it mandates the existence of a machine-readable document representing the product with its dependency relationships. The choice between merging and linking is therefore an engineering decision, and must be justified by the informational costs it entails.

What you lose when you merge everything into one file

Flat merge has a paradox at its core: deduplication. In build tools, eliminating duplicates is good practice; in supply chain analysis, deduplicating components from N documents erases the only necessary information: which service uses which version. Names remain, the map disappears.

• Triage changes nature: from a query on the graph (“which components of product 3.4 depend on libX < 2.9, and in which service?”) to a text search followed by manual verification service by service. This is where MTTR expands, not in writing the patch.

• Lifecycles are decoupled: a merged document is a snapshot that ages upon the first independent deployment of a single service, and every regeneration requires rebuilding the entire file.

• Provenance is lost: hashes and signatures of original documents do not survive merging, so integrity is verifiable only on the aggregate.

Merging remains the correct choice under precise conditions: a substantially monolithic product, a few dozen components, a single release cadence, or an SBOM consumer that cannot resolve external references. In those cases, it produces an autonomous, verifiable artifact with less surrounding infrastructure.

Hierarchical compose: a root BOM that references, not copies

The structure is simple: one product document per version, whose application-type components represent services, each with an external reference to its own SBOM. In CycloneDX, the mechanism is the externalReference of type bom carrying a BOM-Link⁷ in the form urn:cdx:<serialNumber>/<version>, capable of pointing to an entire document or to a single bom-ref within it. In SPDX, the equivalent is achieved using the ExternalDocumentRef pair plus Relationship (DESCRIBES, CONTAINS, DEPENDS_ON).

The resulting properties are those that merging cannot offer: independent regeneration per service, integrity verifiable document by document with separate checksums and signatures, preserved provenance, and manageable file sizes even with hundreds of components per service. It follows the same logic as the hierarchical assembly of a manufacturing bill of materials, where the product level references sub-assemblies instead of listing every single screw.

The constraint, which must be declared: reference resolution is the consumer’s responsibility. If the root BOM points to unresolvable URNs or expired artifacts in a registry with a thirty-day retention policy, the evidence breaks and the document becomes an unfulfilled promise. Composition therefore requires immutable, addressable storage for component SBOMs, with the same retention as the product. Evaluating this type of architectural trade-off, where a format choice becomes an infrastructure requirement, is territory we systematized in our guide to defense models for cloud-native architectures.

The diagram: how to read a root BOM

The edges carry references, not copied content: the root BOM remains the sole authoritative document for the release, and each leaf retains its own signature. The side node is the least obvious point: the vendor SBOM does not enter as an opaque link to a third-party URL, because in that case evidence would depend on the availability of an endpoint we do not control. It must be reconciled first, as explained below.

How do you build the product SBOM inside the pipeline?

Every choice here must be anchored to a requirement: it is generated from the artifact because evidence must reflect what was shipped, identifiers are normalized because component tracking demands it, and it is signed because the integrity of preserved evidence is part of the technical documentation.

Generate from the built artifact, not from source

Operational rule: the Build SBOM is generated from the OCI image or binary produced by the pipeline, and compared with lock-files and source code to detect discrepancies. Where tooling cannot infer (such as static binaries, firmware, or vendorized dependencies), manual records that are tracked and dated are added.

# syft 1.x, trivy 0.5x - use digest, not tag
IMAGE="registry.example.com/checkout-service@sha256:9f2a...c41d"
DIGEST="9f2a...c41d"

# primary generator: CycloneDX JSON output to versioned file per service and digest
syft "$IMAGE" -o cyclonedx-json="sbom/checkout-service-${DIGEST}.cdx.json"

# second scanner on the same artifact, to compare component sets
trivy image --format cyclonedx \
  --output "sbom/checkout-service-${DIGEST}.trivy.cdx.json" "$IMAGE"

Honest note: two generators on the same artifact do not produce identical sets. Syft and Trivy typically diverge on statically compiled binaries and packages installed outside package managers. The delta is not a bug; it is information about analyzer coverage. It should be recorded alongside the SBOM, and certainly not hidden by choosing the tool that returns fewer lines.

Normalize component identity before composing

Composition only works if a component is consistently identifiable across documents generated by different tools at different times. The minimum fields, consistent with CISA minimum elements⁸ and BSI TR-03183 technical guidelines⁹, are:

• component name and exact version;

• vendor or author;

• Package URL (purl)¹⁰, or CPE¹¹ where purl is not applicable;

• artifact hash (SHA-256);

• relationship with the parent component.

The problem is concrete: the same package appears as openssl among OS packages, as libssl3 with the distribution name, and as an embedded dependency of a Go binary. Without a normalized purl, a product triage query returns three distinct entities, making the response to authorities or customers incomplete despite being formally produced. Normalization must be executed in the pipeline as a deterministic, versioned step, never manually during an audit.

Assemble, sign, publish

The product release job constructs the root BOM with metadata.component set to the product and version, application components for each service, and external references to already published SBOMs.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:8f7c1c1e-6a3e-4c0b-9e1a-2d5b7f0a11c4",
  "version": 1,
  "metadata": {
    "component": {
      "bom-ref": "prod-retail-3.4.0",
      "type": "application",
      "name": "retail-platform",
      "version": "3.4.0"
    }
  },
  "components": [
    {
      "bom-ref": "svc-checkout-2.11.3",
      "type": "application",
      "name": "checkout-service",
      "version": "2.11.3",
      "externalReferences": [
        {
          "type": "bom",
          "url": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1"
        }
      ]
    }
  ],
  "dependencies": [
    { "ref": "prod-retail-3.4.0", "dependsOn": ["svc-checkout-2.11.3"] },
    { "ref": "svc-checkout-2.11.3", "dependsOn": [] }
  ]
}

When the consumer cannot resolve references, the alternative path is a hierarchical merge, which at least preserves component nesting:

# cyclonedx-cli 0.32.x - hierarchical merge, preserves assembly structure.
# Merges only canonical, normalized SBOMs from product services.
# One per service: not the raw glob, which would include both Syft
# and Trivy outputs for the same artifact.
cyclonedx merge --hierarchical \
  --input-files \
    sbom/canonical/api-gateway.cdx.json \
    sbom/canonical/checkout-service.cdx.json \
    sbom/canonical/frontend.cdx.json \
  --name retail-platform --version 3.4.0 \
  --output-file product-3.4.0.cdx.json

# cosign 2.x - keyless signing via OIDC, verifiable bundle alongside the document
cosign sign-blob --yes product-3.4.0.cdx.json \
  --bundle product-3.4.0.cdx.json.bundle

Automating these steps within CI/CD, with scanning and signing (for example via Cosign¹²) as native steps rather than optional jobs, is the part of DevSecOps work that we described when discussing tooling and pipeline integration in the cloud. The signed SBOM then goes into immutable storage, and the reference to the file enters the technical documentation of the release along with the tool name, version, and generation date.

Vendor SBOMs, missing information, and evidence lifecycle

Two failure modes remain open even in well-automated setups: documents arriving from third parties and maintaining evidence over time.

Vendor SBOMs are inputs, not the finished artifact

The scenario is recurring. One vendor delivers CycloneDX, a second SPDX, a third a PDF with a list of libraries; the release folder contains three links to three different portals. That is vendor material, not a product record, and in the event of a reasoned request, it fails to answer which version of our product contains the affected component.

Reconciliation follows a precise sequence:

1. convert or normalize identity fields (purl, version, hash) into the internally used schema;
2. integrate components into the product bill of materials, or link them via BOM-Link after verifying that the reference is resolvable and persistent;
3. retain original upstream documents as supporting evidence, noting receipt date and channel;
4. explicitly record what could not be determined.

The fourth point distinguishes defensible documentation from deficient documentation. When a vendor fails to deliver a complete SBOM, the component is not omitted: known unknowns are documented, namely contractual and purchasing evidence, verifiable fields gathered independently by scanning received binaries, hashes and version proof, plus an explicit note on what cannot be determined. A declared absence is evidence; a silent absence is non-compliance.

The implications of this chain of responsibility regarding third-party components and upstream dependencies represent a topic that European regulation shifted from the community onto those who place products on the market, and reconciliation is where that responsibility becomes operational.

How often to regenerate and how long to retain

Regeneration responds to triggers, not a calendar: changes in software or firmware versions, patch releases, changes in vulnerability exploitability status resulting in a VEX (Vulnerability Exploitability eXchange) update, additions, removals, or replacements of components, significant design modifications, or changes in applied standards. Periodic schedules remain useful as a safety net: quarterly reviews of SBOMs and vulnerability status, annual reviews of technical documentation, and a freeze before the end of the support period.

Here composition shows its strongest argument. Triggers are local to the service, so a single document is regenerated and the root BOM is reissued upon product release; in merging, every local trigger requires rebuilding the entire document, risking unwanted deltas on components nobody touched.

Regarding retention, the obligation is long-term, mandated by Article 13 of the CRA¹: at least ten years from placement on the market, or the entire support period if longer, starting from the last unit placed. This excludes CI as a storage location.

For example, if the registry is Google Artifact Registry¹³, the reference service for software composition is Artifact Analysis, which supports SBOM generation and management for archived artifacts alongside vulnerability scanning¹⁴: a solid starting point, but not a compliance archive. Repository default retention and cleanup policies do not align with a ten-year obligation, and must be configured or supplemented with dedicated storage.

To manage this complexity long term, infrastructure must evolve beyond simple file saving. It is worth evaluating specific tooling for document fetching, storage, and transformation, such as Bomctl¹⁵, alongside a graph query layer like GUAC¹⁶ to answer triage queries in a timely manner.

Final point, often overlooked: the SBOM is confidential technical documentation, not public material. It is a component map useful to anyone seeking an entry point. Release to market surveillance authorities occurs upon reasoned request (in Italy, the reference role belongs to ACN), and to business customers under NDA, tracking who received which version and when. International convergence on these principles is documented in the joint guidance A Shared Vision of Software Bill of Materials for Cybersecurity¹⁷ published in September 2025 by CISA, NSA, and nineteen partners.

Operational lessons

The decision rule fits in two lines: if the product has more than one independent release cycle, hierarchical compose is the only maintainable strategy; below that threshold, merging costs less and easily passes an audit.

Three things we would do differently, based on our experience with multi-service pipelines:

1. Treat component SBOM storage as a long-term artifact from day one, not as CI output with default retention. Recovering expired documents after six months means regenerating them from images that no longer exist.
2. Normalize identifiers in the pipeline before volume makes the operation retroactive. At three hundred documents, retroactive normalization becomes a project, not a step.
3. Measure orchestration quality with a single, timed question: how long does it take, starting from a CVE, to list affected product versions and impacted services? If the answer is measured in hours, the evidence architecture is failing, regardless of formal document compliance.

One issue remains open and must be stated: consumer maturity in resolving BOM-Links is still uneven, making this the strongest argument against pure composition today. A defensible strategy maintains the linked root BOM as the authoritative source while being able to produce a flattened view on demand as a derived export, never as the reference document.

The next and final article in the series covers observability (logs, metrics, and traces) as the technical foundation for meeting notification and reporting obligations under CRA and NIS2.

We work on these topics daily in our software supply chain security practice, and as members of OpenSSF¹⁸, CNCF, and LF Europe, we contribute to defining tools that make this evidence verifiable rather than merely declared.

Need a discussion, an audit, or dedicated consulting on security, DevSecOps, or CRA compliance? Contact our experts.

Notes and sources

Drupal 12.0.0 is planned for the week of December 7, 2026¹. Two days later, on December 9, 2026, Drupal 10 reaches its End of Life. Together, these two dates, rather than the new major version itself, rewrite the priorities of an IT roadmap for the next four quarters.

Platform requirements are already official: PHP 8.5 as the minimum runtime, Argon2id as the default password hashing algorithm, and six core modules being removed. This means preparation can begin today, rather than becoming an emergency as release day approaches.

Upgrading to Drupal 12 is not a migration project: it is an infrastructure modernization and custom code cleanup project. As such, and depending on your starting version, it should be launched months in advance, not in the weeks leading up to the release. Below are the verified requirements, the official timeline, an operational checklist with typical owners for each task, and the reason why core AI capabilities will arrive well before December 2026.

What really changes with Drupal 12: requirements, security, and a leaner core

Drupal 12 raises the minimum runtime to PHP 8.5, adopts Argon2id for password hashing, removes six modules from core, and recommends Composer 2.9.3. It is not an architectural rewrite: it is the removal of deprecated code accumulated throughout the Drupal 11 lifecycle.

It is worth looking at the column of what isn’t changing as well. The web server layer and browser policy remain stable: no network infrastructure migration, no work on reverse proxies, ingress controllers, or CDNs.

Drush² deserves special mention. For years it has been the de facto standard for command-line administration, created to fill major limitations in Drupal core’s CLI. Today, the direction has reversed: Drupal 11.4 introduces an extensible native CLI (vendor/bin/dr), allowing modules to register commands directly in core³, and the community has already published an official guide for porting Drush commands to the new interface⁴.

The stated intention is to write Drupal commands directly, making it likely that the migration will be complete with Drupal 12. At the same time, the initial draft of the Drupal 12 upgrade documentation⁵ features Drush 13 in its example code snippets, signaling that support might continue. There is no official confirmation on this point yet: we will have to wait for the documentation to mature to understand how things will evolve.

On the security front, the switch from bcrypt to Argon2id⁶ is the most notable change. Argon2id is a memory-hard algorithm: it deliberately saturates RAM during hash calculation, making GPU-accelerated brute-force attacks ineffective, which is precisely bcrypt’s weakness. Re-hashing existing password hashes occurs transparently upon each user’s first login, with an automatic fallback to bcrypt if the PHP environment lacks the necessary support: no forced password resets, no downtime.

This brings up a point that official documentation does not cover. PHP container images must include libsodium support or the argon2 extension; otherwise, the site silently remains on bcrypt without throwing any visible errors. Furthermore, PHP-FPM pods must be reviewed regarding memory limits, as authentication spikes will consume more RAM than before. Anyone working in regulated industries will find useful context in how Drupal core addresses compliance and data protection requirements, as reducing the attack surface is part of the same strategy.

Six modules leave core and move to contrib (Ban, Contact, Field Layout, History, Migrate Drupal, and Migrate Drupal UI): if your site uses even one of them, replacing it or installing its contrib version must be put on the roadmap now, not when the upgrade is already underway (especially if your site uses Contact for official forms, making it a business priority). The benefits of a leaner core are tangible: a smaller attack surface, lighter builds, and faster CI/CD pipelines.

Completing the picture are Gin as the default administration theme and alignment with Symfony 8, as even-numbered Drupal major releases are anchored to Symfony LTS (Long Term Support) releases, a key factor for organizations seeking extended lifecycles.

When is Drupal 12 released, and why is Drupal 10 the real deadline?

Drupal 12.0.0 will be released the week of December 7, 2026, alongside Drupal 11.5.0. Drupal 10 reaches End of Life on December 9, 2026⁷. Drupal 11 will remain supported until mid-to-late 2028. Those on Drupal 10 face a hard deadline at the end of 2026; those already on Drupal 11 have roughly two years of runway.

There are four key verifiable milestones in the cycle:

1. September 11, 2026: deadline for completing beta requirements.
2. Week of September 14, 2026: release of Drupal 12.0.0-beta1 and 11.5.0-beta1.
3. Week of November 9, 2026: release of rc1 for both release lines.
4. Week of December 7, 2026: stable release.

Maintenance windows remain fixed: bugfixes on the first Wednesday of the month, security releases on the third Wednesday. Having this level of predictability twelve to twenty-four months in advance is rarely emphasized in comparisons with proprietary DXPs, yet for an IT Director, it is worth more than any individual feature: it allows allocating budgets within already-approved financial cycles.

The real risk, however, isn’t missing the launch of Drupal 12: it is facing a double hop. The minimum source version for upgrading is Drupal 11.3.0⁸, because all previous update scripts have been removed from the Drupal 12 codebase.

If you enter December 2026 on Drupal 10, you will have to execute two sequential updates under pressure, not one. The lessons from previous cycles (from Drupal 7 end of support on January 5, 2025, to Drupal 9 reaching EOL in November 2023⁹) mirror what we gathered in our analysis of the transition to Drupal 10: the cost of an upgrade increases with delay, not with the technical distance between versions.

The overlap between Drupal 11 and Drupal 12 is therefore a governance lever, not a technical detail. With Drupal 11 supported until mid-to-late 2028 and the most impactful deprecations from Drupal 11.3 deferred to Drupal 13, the upgrade fits into routine maintenance. In budget terms: teams on Drupal 10 must complete their move to Drupal 11 by Q3 2026 to avoid overlapping with the December release window.

How to prepare a Drupal site today for the upgrade to Drupal 12

Preparation consists of four parallelizable tracks: updating the site to Drupal 11.3 or higher, auditing deprecated APIs using Upgrade Status and Drupal Rector, updating runtime and container images to PHP 8.5, and adding compatibility checks into the CI/CD pipeline. None of these four steps requires waiting for release day.

Here is the operational checklist, along with the typical owner for each item:

1. Alignment with Drupal 11.3.0 or higher (Drupal tech lead): non-negotiable prerequisite.
2. Audit of custom code and contrib modules with Upgrade Status (tech lead + developers): yields the deprecation inventory.
3. Automated refactoring with Drupal Rector¹⁰ (developers): applies transformation rules across the codebase.
4. Updating container images to PHP 8.5 (platform/DevOps team), verifying extensions required for Argon2id.
5. Verification of managed databases (platform team): checking RDS/Aurora and Cloud SQL against new minimum versions of MariaDB and PostgreSQL.
6. Replacement of the six removed core modules (analyst + developers), starting with Contact.

The key fact that mitigates perceived risk is Project Update Bot’s coverage: over 80% of deprecated APIs in Drupal 12 are handled by automated Rector rules¹¹ (some generated with AI assistance), with patches submitted directly to issue queues and final control left to maintainers.

However, that 80% applies to the contrib ecosystem. For enterprise custom code, where business value and technical debt converge, automated coverage is lower: proprietary integrations, custom themes, and tailored modules are what truly dictate upgrade duration and effort.

This is where automation ends and engineering begins. Custom themes must be checked against Gin as well as the new Styles API and Design Tokens API introduced in Drupal 11.3 and 11.4¹², which decouple theming from the application layer. Custom modules must be covered by automated tests running in pipelines. And Composer dependency management must be treated as a software supply chain security concern, not just a build step: the recommended Composer 2.9.3¹³ itself stems from a security patch. We have summarized the full methodological framework for code cleanup in our guide to upgrade planning and Drupal CMS migration.

A note from our experience: we have managed numerous enterprise upgrade projects, such as Caleffi, where we oversaw the transition from Drupal 7 to Drupal 10 and subsequently to Drupal 11. In that context, we also open-sourced the Drush pre-deploy module, which executes custom hooks before update:db during multi-environment deployments¹⁴. It is precisely this kind of control that turns a major version upgrade from a manual event into a repeatable operation.

The core AI wave: why Drupal 11.4 is the bridge to Drupal 12

The capabilities destined to transform daily workflows on Drupal projects (AI workflows, Context Control Centre, new design APIs) are not waiting for Drupal 12: they arrive in minor releases of Drupal 11. Updating today delivers functional innovations immediately while preparing for the upgrade in a single work cycle.

There is an old misconception to dismiss: major Drupal releases today remove deprecated code; they do not introduce features. For decision-makers, the takeaway is clear: postponing updates “while waiting for Drupal 12” means missing out on available features for twelve months without gaining any additional stability.

What is already available or coming to core and the broader ecosystem:

• Hundreds of AI modules (a year ago, when the Drupal AI Initiative was announced, there were already 290+ modules).

• The Context Control Centre in Drupal CMS 2.1 (based on core 11.3), which codifies brand voice, design systems, and regulatory requirements once, ensuring all AI outputs remain compliant¹⁵.

• The Human in the Loop pattern as recommended governance: AI generates drafts, humans review and approve before publishing¹⁶.

• Native HTMX¹⁷ integration in Drupal 11.3¹⁸, reducing the JavaScript payload¹⁹ for browser-server interactions by up to 71% by taking over from Drupal’s AJAX API; BigPipe remains in place to handle progressive server-side rendering.

• Drupal Canvas, the visual component-based page builder, and the experimental native command-line interface in Drupal 11.4²⁰.

There is also data that will resonate with CFOs: Drupal core 11.3 (on which Drupal CMS 2.1 is built) delivered the biggest performance boost in a decade across the ecosystem²¹, cutting database queries on uncached pages by 50% and significantly optimizing other operations, directly lowering cloud infrastructure costs and improving traffic spike management²². This is a benefit unlocked by updating minor versions, not by waiting for Drupal 12 in December.

In terms of contributions, you can already leverage the Guardrails system we contributed to the Drupal AI 1.3 module: an architecture that intercepts and filters communications with LLMs by applying pre- and post-processing validation rules to prevent sensitive data exposure²³. In the same realm sits search_api_typesense, our module for semantic search. We delve into this in detail in our overview on the evolution of Drupal AI and LLM integration. Further announcements are expected at DrupalCon Rotterdam, running September 28 to October 1, 2026.

The underlying discipline is identical: maintaining a continuous update process that brings AI features into production is precisely what turns the Drupal 12 upgrade into a non-event.

What to put on your roadmap now

1. If you are on Drupal 10 (or earlier), the upgrade to Drupal 11 must be completed by Q3 2026: after that, the window overlaps with the December release.
2. If you are on Drupal 11, initiate the deprecation audit and container updates to PHP 8.5 over the next two quarters.
3. In both cases, unlock AI capabilities and new design APIs by keeping up with minor updates, rather than waiting for December 2026.

If your Drupal release process is not automated via CI/CD with compatibility testing, upgrading to Drupal 12 won’t be a code problem; it will be an organizational one. Official documentation and upgrade guides cover commands. They do not cover your custom infrastructure or custom codebase.

For a readiness assessment of your custom code, themes, and infrastructure, speak with our Drupal team: as a Drupal Gold Certified Partner with deep Cloud Native expertise, we can evaluate what needs to be done and establish a quarter-by-quarter execution plan.

Notes and sources

Drupal¹ powers approximately 14% of the top 10,000 websites in the world². This is a remarkable figure, bucking the trend of the CMS’s decline in the generalist market. The question for those evaluating the platform today is a practical one: what really changes with the new strategy, and is it worth betting on for an enterprise or mid-market project?

The launch of Drupal CMS on January 15, 2025, coinciding with the project’s 24th birthday and the end of support for Drupal 7³, marked a turning point. With the Product Strategy 2.0⁴ published in June 2026, the Drupal Association redefined the course: Drupal CMS 2.0 adopts an agentic-first approach and opens up to the mid-market, without sacrificing the enterprise solidity that remains its core market.

Recipes, Drupal Canvas, and native AI are not just marketing labels. The thesis of this article, from our perspective as a long-time contributor to the project, is simple: simplifying does not mean dumbing down, but empowering those who build.

What is Drupal CMS and what changes with strategy 2.0?

Drupal CMS⁵ is an out-of-the-box distribution built on top of Drupal Core, born as the Starshot project in August 2024. While Drupal Core is the flexible framework designed for developers, Drupal CMS adds guided workflows, pre-defined components, and browser-based installation, so that even a non-technical profile can launch a site in minutes rather than days.

The terminological confusion between the two levels is the most searched point by those approaching the platform. Clarifying it is crucial: you choose Core when you need to build a custom solution; you choose the distribution when time-to-value matters. We have analyzed this positioning extensively, explaining how Drupal CMS redefines content management for business, which is useful for those who need to frame the technological transition.

The heart of the simplification is Recipes⁶: declarative configuration packages, defined in recipe.yml files, that combine modules, configurations, and sample content. They are not limited to installation: they can be applied at any point in the project lifecycle. Making them possible required the development of 4 new APIs integrated into the core. Through the Project Browser, a user can assemble an events site in a few minutes by installing recipes and modules without writing code⁷.

The three innovations that qualify strategy 2.0 compared to Starshot are:

• Recipes and Site Templates⁸, for guided onboarding and reduced time-to-value;

• Drupal Canvas⁹ for drag-and-drop visual site building;

• Drupal AI¹⁰ and integrated hosting, with simplified distribution (also installable locally via DDEV).

The jump between the two versions is concrete: the initial Starshot strategy aimed for ease of use, while 2.0 expands the scope to hosting, distribution, and AI, extending the timeline to June 2028¹¹. From our experience in the field, pre-defined components and guided workflows reduce implementation times by up to 40%.

Why the agentic-first approach redefines the role of the CMS?

Agentic-first means designing every CMS workflow so that it can be operated by an AI agent, not just adding a widget that generates text in the editor. AI becomes infrastructure: it operates within taxonomies, permissions, and approval workflows, with humans maintaining supervision over quality and governance. It is a shift in the role of the CMS, from a container to an orchestratable platform.

Is AI in a CMS a feature or infrastructure? Drupal’s roadmap answers clearly: every internal process must be natively ready to be orchestrated by intelligent agents. We have worked on this vision since the early stages of Starshot, contributing specifically to the Drupal AI Initiative by creating AI agents and the guardrails system, writing tests, improving documentation, and producing recipes¹².

This idea of Drupal AI as connective tissue, rather than a disconnected assistant, is at the heart of the new agentic-first approach to Drupal development, where the CTO’s role evolves toward agent orchestration.

Governance is the condition for all of this to work in production. Drupal structures it on three pillars:

• Context Control Center¹³: centralized definition of brand, persona, and topics assigned to models, so that output remains consistent with company guidelines;

• Human in the Loop: AI generates drafts, people review and approve before publication, relying on native Workflow and Content Moderation modules;

• versioning and auditing of generated content, to keep every change transparent and reversible.

Here emerges the gap that enterprise decision-makers must manage. Where do the models run? External LLM APIs have a cost per token and raise data leakage risks, with implications for GDPR and the EU AI Act. The choice between external models (such as those integrated into CKEditor for content suggestions) and self-hosted models on cloud-native architectures becomes a compliance decision, not just a technical one. Guardrails serve exactly this purpose: defining what AI can and cannot do.

AI as a skill gap filler, not a noise generator

AI integrated into Drupal is not for producing more content, but better content. It democratizes vertical skills (SEO, copywriting, accessibility) that are often lacking in editorial teams, raising the overall quality standard.

The opposite risk is real: speed without quality control equals brand risk. A CMS that floods channels with flat text worsens information overload instead of solving it.

The stated goal is to produce value, not volume, and Drupal’s governed architecture is the framework of rules that makes it possible. Furthermore, in Drupal, AI is seen as a catalyst for human skills, not a replacement for people.

Does the push toward the mid-market strengthen or weaken the enterprise?

Opening up to the mid-market is not a fallback, but an investment in the vitality of the ecosystem. The enterprise remains Drupal’s core market, where the platform boasts unusual penetration among organizations with over 10,000 employees. Attracting medium-sized projects broadens the base of contributors and developers without compromising the robustness needed by large organizations.

The segment it aims to open up to most, as declared by strategy 2.0, is mid-market projects, with total budgets between $30,000 and $120,000 (approximately €25,000-100,000). Drupal does not target entry-level sites nor compete with low-end website builders, which remain explicitly out of target: the goal is to bridge the gap between those sites and large enterprise architectures, offering reduced time-to-value through ready-to-use Site Templates.

For a decision-maker, the numbers that matter are economic and related to stability:

• Savings of up to 60-80% on three-year TCO compared to other solutions like Adobe Experience Manager, thanks to the elimination of annual licenses¹⁴;

• an ecosystem of over 10,000 active developers globally, with thousands of modules ready to use¹⁵;

• open-source nature and absence of vendor lock-in¹⁶, with control over code, data, and roadmap as digital sovereignty assets.

The enterprise remains the core for verifiable reasons. The Economist, NASA, and the University of Oxford use Drupal for their digital experiences¹⁷. The American Medical Association consolidated WordPress and Drupal sites into a single platform. The Nestlé case¹⁸, presented at DrupalCon Vienna 2025, shows a multi-brand design system structured on three levels (core, UI components, brand overrides) that governs over 100 sites and allows for the instantiation of new projects in days instead of weeks. These are scenarios that validate the architectural and security advantages that make Drupal the choice for complex corporate sites, the same ones that strategy 2.0 now extends to the mid-market.

Want to achieve similar results for your organization? Talk to our specialists to design a custom transition to Drupal.

Canvas, Display Builder, and flexibility as the true differentiator

The simplification of site building does not impose a single tool. Drupal Canvas takes a central role in the roadmap for visual editing, but Drupal’s historical flexibility offers alternatives like Display Builder¹⁹ for projects with different needs. Not a mandatory path, but architectural options chosen based on the project.

The Visual Builder, or Experience Builder, unifies Layout Builder and Paragraphs into a drag-and-drop interface that allows installing, configuring, and extending Drupal entirely from the browser²⁰. Canvas is the central direction of the roadmap, and we have seen its use in production, along with native design systems and enterprise AI, among the practical innovations that emerged at DrupalCon Vienna 2025.

Flexibility has always been Drupal’s strength, and this is where differentiation happens. At the Drupal X Business²¹ event, we explored Display Builder as an alternative designed for enterprise contexts with complex design systems that require granular layout control. The practical choice depends on the context:

• Drupal Canvas when editorial autonomy and speed of page assembly by business teams are needed;

• Display Builder when the project has an articulated design system and requires fine control over components and structure.

The future of theming reinforces this flexibility. Drupal 11.3 and 11.4²² introduce the Styles API²³ (with utilities for typography, colors, spacing, and a themes & modes system) and the Design Tokens API²⁴ (with scoped values that become CSS variables only at runtime), paving the way for the arrival of Drupal 12 expected in December 2026²⁵, about which news is already starting to circulate and to which we will soon dedicate a specific article.

The goal is to separate theming from the application and automate the workflow from Figma to the browser, a direct advantage for multi-brand consistency and accessibility (WCAG 2.1 AA, European Accessibility Act).

Added to this is the native support for headless architectures, traditional or hybrid via REST, JSON:API, and GraphQL, which distinguishes Drupal from pure headless solutions like Contentful, Strapi, and Storyblok²⁶. This modularity, not a single tool, is the lasting competitive differentiator.

What it means for those evaluating Drupal CMS today

Product Strategy 2.0 does not dumb down Drupal: it empowers those who build it (agencies and developers) to deliver value to business teams more quickly. Those evaluating the platform today should read the change along three axes.

• Agentic-first as governed infrastructure, not as a feature: AI operates within workflows, permissions, and Human in the Loop patterns, with compliance (GDPR, EU AI Act) as a project constraint.

• Opening to the mid-market that provides vitality without affecting the enterprise, with a TCO up to 60-80% lower than AEM and an open-source ecosystem free of vendor lock-in.

• Architectural flexibility between Canvas and Display Builder as a differentiator that survives trends.

To maximize the ROI of your digital presence, plan a migration to Drupal or request an assessment of your architecture from our team. As long-time contributors to the project and the first Drupal Gold Certified Partners in Italy, we will provide you with a clear action plan to optimize performance, reduce technical debt, and ensure regulatory compliance.

Notes and sources

Who is legally responsible for a vulnerability in a library downloaded from a public repository, maintained for free by a volunteer contributor, when that library ends up at the heart of a CE-marked commercial product? With the Cyber Resilience Act, this question stops being theoretical and becomes a risk management problem for every European CTO.

Open source technologies are used by 90% of organizations worldwide, according to the Linux Foundation¹. This is not a marginal detail: a 2022 study by the Linux Foundation itself estimates that 70-90% of any modern codebase is composed of free and open source components.² Similarly, the 2024 Synopsys report indicates that 96% of commercial codebases contain open source software and 77% of all code in those same examined codebases originated from open source code.³

In other words: for the most part, companies did not write the software they sell.

This is where the central tension of the Cyber Resilience Act (CRA) arises: the European regulation introduces legal responsibilities for products built largely on components that, formally, no one “owns”. When you integrate dozens of libraries into a commercial product, who is responsible for the vulnerability? The answer is no longer obvious.

In this article, we clarify what changes for those who use and contribute to open source, which risks concretely fall on the company, and how to structure a software supply chain governance compliant with the CRA, without stopping to benefit from the competitive advantage that open source code guarantees.

What is meant by open source and is software really free?

Open source is software whose source code is publicly accessible, modifiable, and redistributable according to licenses approved by the Open Source Initiative (OSI). But free accessibility of the code does not mean zero cost: the cost shifts to integration, maintenance, security, and compliance. Those who confuse “free” with “at no cost” underestimate the very items that the CRA now makes mandatory.

The distinction between terms matters more than it seems. Free software, in the sense of the Free Software Foundation (FSF) founded by Richard Stallman, focuses on user freedoms and adopts copyleft licenses like the GNU General Public License (GPL), which obliges the redistribution of derivative works under the same conditions. Open source, promoted by the OSI, also allows for more permissive licenses oriented toward commercial adoption. Proprietary software, on the other hand, closes the code and transfers operational responsibility to the vendor, at the price of vendor lock-in.

The pervasiveness of open source in companies is concrete and daily, well beyond technical environments:

• Open source ERP and CRM systems that manage core business processes (with solutions like Odoo or Dolibarr ERP CRM challenging traditional vendors).

• Open source intranet applications for internal collaboration and document management.

• Open source IT auditing software for continuous security monitoring and compliance.

• Office application suites as alternatives to proprietary platforms, such as the historic Apache OpenOffice and LibreOffice, or the new Euro-Office launched in June 2026.

• Open source software for financial management (e.g., Money Manager Ex) and flexible e-commerce platforms.

Beneath this application surface operates an entirely open infrastructure: Linux as the server operating system, Kubernetes for container orchestration under the aegis of the Cloud Native Computing Foundation, Apache Kafka for data streaming, Ansible for automation. The vision of open source as a public good and a lever for sovereignty, which at SparkFabrik we consider the foundation of our software development, stems precisely from recognizing that this invisible layer supports the entire digital economy.

Open source, free software, or proprietary: a comparison table

The strategic takeaway is clear: open source reduces vendor lock-in but redistributes operational and security responsibility to the user. It is exactly this shift that the CRA formalizes on a legal level.

How the Cyber Resilience Act redistributes responsibilities for open source

The CRA introduces the figure of the open source steward and transfers security obligations to those who place products on the market, not to those who develop code collaboratively. However, the original wording of the regulation did not draw this line clearly, risking involving even upstream contributors in responsibilities they could not reasonably sustain.

The legal crux was effectively illustrated by Mirko Boehm of Linux Foundation Europe: the CRA, in its first version, did not distinguish between upstream collaborative development and placing a product on the market, and did not limit responsibility to the intended use. A volunteer contributor could have been held liable for vulnerabilities even in completely unforeseen use scenarios, such as the paradoxical case of a code fragment ending up controlling a nuclear power plant. It is the type of risk that alarmed the entire community, a debate that we reconstructed by analyzing the concerns of the open source world.

Why can’t foundations simply absorb these obligations? For a well-documented economic reason. Many open source projects receive no funding and, even by distributing available funds equally across all projects, it would amount to little more than $250,000 each: a figure that is perhaps enough to pay a community manager and organize a few meetups, but certainly not to maintain full-time security personnel.⁴ Furthermore, as Linux Foundation Europe clarifies, those funds arrive tied to specific projects by donors (donor-directed funds), to the point that not even the foundation itself could divert them to solve the security problems of another project; and other open source foundations often have even more limited resources.

Loading open source maintainers with the security-by-design obligations of the CRA⁵, at a stage where the long-term sustainability of many projects is already being questioned by the contributors themselves, risks proving counterproductive.

The response was the #FixTheCRA initiative, coordinated by Linux Foundation Europe on five fronts: proposing amendments through Open Forum Europe, disseminating critical issues, an open letter signed by a coalition of open source foundations, roundtables with European institutions (with panels at KubeCon Europe and the Open Source Summit), and the creation of permanent collaboration venues. SparkFabrik participates in this ecosystem as a member of Linux Foundation Europe and OpenSSF⁶, and our CTO Paolo Mainardi sits on the LF Europe Advisory Board.

Who is responsible for vulnerabilities: upstream, steward, or manufacturer?

The CRA distinguishes three roles with different responsibilities:

• Upstream contributor: develops code collaboratively, outside of commercial logic. They are excluded from the direct obligations of the regulation.

• Open source steward: a new figure introduced by the CRA, with reduced and proportionate obligations (typically foundations and organizations that support projects).

• Commercial manufacturer: the one who places the product on the market with the CE marking. They assume full legal responsibility for security.

The takeaway for the decision-maker is direct: if your company integrates open source into a commercial product, the legal responsibility falls on you, not on the upstream project. The CE marking certifies that you are the one guaranteeing the compliance of the entire stack, dependencies included.

What risks do European companies building on open source face?

There are three main risks: the increase in compliance costs borne especially by SMEs, the possible withdrawal of software from the EU market by communities, and the impact on European digital sovereignty initiatives. These are risks that hit asymmetrically those who use open source to compete.

Analyzed by level, the risks are structured as follows:

• Economic risk: the CRA could impose additional costs on the use of and contributions to open source, primarily borne by European companies, penalizing SMEs that base their ability to compete with large incumbents on open innovation.

• Supply chain continuity risk: communities might refuse to make software available in the EU, leaving distribution to non-EU commercial intermediaries, impacting Gaia-X⁷, SovereignEdge⁸, and Next Generation Internet⁹.

• Strategic risk: the CRA’s critical product classes coincide with fundamental open source technologies.

This third point deserves attention because it contains a paradox. Class II of the CRA, subject to some of the strictest security requirements, includes server operating systems, hypervisors, and container runtimes: exactly the open technologies that support the European cloud infrastructure. We explored this tension between regulation and competitiveness in the analysis of how the CRA affects the strategic autonomy of the Union.

The paradox deepens on the sovereign cloud front. Offerings like AWS European Sovereign Cloud, Google S3NS, and the Bleu project present themselves as European but remain architecturally controlled by non-European hyperscalers¹⁰. In this framework, open source, and not the “sovereign” label applied to proprietary technologies, remains the real lever of technological independence for the continent’s organizations. For a European CTO, this means prioritizing stacks based on verifiable open source technologies in their cloud procurement strategy.

How to manage open source responsibilities in compliance with the CRA

Managing responsibilities means moving from passive consumption of open source to structured governance: dependency inventory, security-by-design, active contribution to projects, and documentary transparency toward the market. It is not a bureaucratic fulfillment, but a change in how the company conceives its software supply chain.

The first pillar is supply chain governance. Total visibility of dependencies is needed, including transitive ones that no one consciously selected. In this area, our experience is direct: SparkFabrik is the maintainer of DruBOM, a Drupal module that integrates Anchore Syft to generate the complete Software Bill of Materials of an installation, including PHP and JavaScript dependencies. It is the same approach we described when talking about how to map dependency risks for CE marking.

The second pillar is methodological. Software development compliant with the CRA requires security controls integrated from the early stages, not added later. At SparkFabrik, we practice a principle of security enablement over enforcement: security is not a gate imposed downstream by compliance teams, but a capability placed in the hands of developers, who become conscious actors in the product’s security posture.

The third pillar is cultural: moving from users to contributors. Sachiko Muto, in the context of Drupal4GovEU, argued that institutions must participate in open projects by contributing their own developers, not just by funding them¹¹. It is the same philosophy summarized by Paolo Mainardi, CTO of SparkFabrik¹²:

“Open Source is a public good that must be supported and funded in a new, modern way: like public infrastructure”.

Contributing actively reduces strategic risk and strengthens the sustainability of the projects the company depends on.

In operational terms, the high-level path is divided into five steps:

1. Map all dependencies, direct and transitive, with composition analysis tools.
2. Classify products by risk class according to the CRA scope.
3. Integrate security controls into the development cycle, from a DevSecOps perspective.
4. Define update and vulnerability disclosure policies.
5. Contribute upstream to projects critical to your business.

It is worth noting that openness does not only concern traditional infrastructure but extends to the dual relationship between open source and artificial intelligence. On one hand, AI allows for managing open projects on an unprecedented scale, allowing a single developer to quickly reach the productivity of an entire team; on the other, open source accelerates the progress of AI itself through shared models and frameworks. 72% of developers, according to the 2024 Stack Overflow survey, declare a favorable position toward the use of AI tools in their workflow¹³. Integrating these new generative components into your commercial products means inheriting further dependencies: the governance you build today must also withstand this complexity, ensuring that AI adoption respects the same traceability and security obligations imposed by the CRA.

From passive dependency to open source governance

The CRA is not a threat to open source, but an accelerator toward a mature management of software supply chain responsibilities. The regulation formalizes on a legal level a truth that technical teams have known for a long time: whoever sells a product is entirely responsible for it, including the parts inherited from open source code.

Companies that structure open source governance today, with dependency inventory, security integrated by design, and active contribution to the projects they depend on, transform a regulatory obligation into a competitive advantage and a concrete lever for digital sovereignty. It is the difference between suffering compliance and using it as a quality accelerator.

In the next article in the series, we will address how to manage the complexity of multiple Software Bills of Materials in large, multi-service projects, between SPDX and CycloneDX formats and the automation of transitive dependencies.

If you want to evaluate the maturity of your open source supply chain and plan for regulatory compliance, our support path on the Cyber Resilience Act provides the experience of a KCSP team, member of CNCF, Linux Foundation Europe, and OpenSSF. Contact us and tell us about your challenges.

Notes and sources

Software supply chain security is at the top of security priorities for 2026, and analysts like Gartner and specialized vendors like Chainguard converge on one point: supply chain attacks are no longer a remote possibility, but the preferred entry vector. The problem is no longer knowing what to protect, but how to make it automatic and demonstrable.

With the Cyber Resilience Act¹, compliance stops being an annual audit and becomes a continuous process that lives inside pipelines. The EU regulation imposes security updates for at least five years and the notification of exploited vulnerabilities within 24 hours (as provided for in Article 14)², obligations that are incompatible with sporadic manual checks. It is no coincidence that the European legislator acted after cybercrime exceeded a global cost of 5.5 trillion euros per year as early as 2021³, with projections estimating 10.5 trillion dollars in 2025 and 15.63 trillion in 2029⁴.

The scale of technical debt makes the problem concrete. The 2024 OSSRA report found that 91% of the codebases examined contained components that were ten versions or more behind⁵. In the 2026 edition of the OSSRA report, the debt remains real: 41% of components in codebases are ten versions or more behind, 22% are six to ten versions behind, and 18% are three to five (only 7% are on the latest version). This data must be read in a context where codebase complexity is increasing (+35% file count YoY), the number of components is increasing (+30% YoY), and the number of vulnerabilities per single codebase has more than doubled (+107% YoY).⁶ It is therefore clear that repeating a manual check of this technical debt for every release, multiplied by five years of mandatory support, is simply unsustainable.

Automating scanners and policies is not enough. Legal responsibility remains with the manufacturer even when a pipeline performs the check. An architecturally correct and auditable automation requires rigorous tool selection criteria, native integration into development processes, and the awareness that technical delegation does not transfer the legal burden.

What does automating Cyber Resilience Act compliance in a cloud-native pipeline mean?

Automating CRA compliance means transforming regulatory obligations (SBOM generation, vulnerability scanning, artifact signing, and blocking non-compliant releases) into checks performed automatically at every commit and deployment, integrating them into the software lifecycle rather than applying them downstream as a documentary check.

The methodological foundation lies in the evolution of operational practices, where security checks anticipate the release phase to integrate directly into the pipeline. This approach, known as DevSecOps, translates the regulatory principle of security-by-design into practice. We have described in detail how this model integrates security into the software lifecycle in a dedicated analysis of DevSecOps applied to the cloud, which clarifies why automated checks increase release speed instead of slowing it down.

The second key concept is continuous compliance. The CRA imposes support and security updates for at least five years or for the product’s useful life. Compliance therefore becomes a state to be maintained, not a goal to be reached once. A secure library today can host a critical CVE tomorrow. Pipelines become the operational arm that re-evaluates compliance at every build, intercepting drift before it reaches production.

In practice, four regulatory obligations translate into operational mechanisms. SBOM generation occurs at every build, producing a versioned and machine-readable format. Simultaneously, known vulnerability scanning crosses components with CVE databases. The process then requires signing and verifying the provenance of artifacts placed on the market, culminating in the enforcement of deployment policies to block releases that violate requirements.

The operational impact is measurable. According to our experience, a structured approach with integration into CI/CD pipelines, identification of direct and transitive dependencies, crossing with vulnerability databases, and continuous validation, reduces the mean time to remediation (MTTR) of vulnerabilities by up to 80%⁷.

Which tools to choose for automated compliance monitoring?

The key tools for CRA monitoring in a cloud-native environment are Syft for SBOM generation, Trivy or Grype for vulnerability scanning, Cosign and Sigstore for signing and verifying artifact provenance, and OPA Gatekeeper or Kyverno to block non-compliant deployments on Kubernetes.

Tool selection requires rigorous architectural criteria. Adopting a solution just for its popularity quickly generates operational debt. The parameters we evaluate in our projects are five: native integration with the existing CI/CD pipeline, support for standard SBOM formats such as SPDX and CycloneDX, verifiable signing capability, enforcement model (admission control in production versus scanning at build time) and, above all, the generation of persistent auditable evidence.

SBOM generation and vulnerability scanning

Syft⁸, developed by Anchore, produces SBOMs in standard formats from container images and filesystems, keeping the moment of inventory separate from the moment of analysis. The actual scanning is done by Aqua Security’s Trivy⁹ or Grype, which cross-reference the detected components with CVE databases.

The relevant operational distinction is between scanning the filesystem, container images, and transitive dependencies. The latter is often the most insidious, because a vulnerable component enters through a third-level dependency that no one explicitly declared. The trade-off to manage is noise: a threshold that is too aggressive generates false positives that paralyze delivery, one that is too permissive nullifies coverage. Prioritization by severity and context is the lever to keep the signal reliable.

Artifact signing and provenance

Cosign, part of the Sigstore project¹⁰, signs container images and guarantees integrity and provenance, with both key-based and keyless workflows based on ephemeral keys and a tamper-proof transparency log. This aligns the pipeline with the SLSA framework for artifact integrity.

For the CRA, signing is central because it demonstrates the chain of custody of artifacts placed on the market. A signed and verifiable image is the technical proof that the distributed product is the one built by the pipeline, not a binary altered downstream. As members of CNCF and OpenSSF, we have built direct expertise on these tools, also shared in a vertical technical event on software supply chain security dedicated to the operational use of Sigstore and Kyverno.

Policy enforcement on Kubernetes

OPA Gatekeeper and Kyverno operate as admission controllers. They intercept deployment requests and block containers without a valid signature or with critical vulnerabilities in real time, before they reach the cluster. This is the point where policy stops being a recommendation and becomes an applied constraint.

The choice between the two depends on who manages the policies. OPA Gatekeeper uses Rego, an expressive language but with a steep learning curve. Kyverno, a CNCF graduated policy engine, defines native Kubernetes policies in YAML, making it more readable for compliance teams not specialized in policy languages. The decision criterion is based on how much the policies must remain inspectable by those responsible for the audit.

How to integrate policy-as-code controls into DevSecOps pipelines

Controls are integrated by defining policy as code versioned in the same repository as the code, executing them as blocking gates in CI/CD pipelines, and applying them in production via admission controllers on Kubernetes. This GitOps approach makes every change traceable and demonstrable to certification bodies.

The end-to-end flow passes through precise stages, producing persistent evidence for each. The code commit triggers the pipeline, starting SBOM generation with Syft on the newly built artifact. Immediately after, Trivy or Grype perform the vulnerability scan against CVE databases. If the checks pass, the image is signed with Cosign and recorded in the Sigstore transparency log. A policy gate in CI evaluates the overall results to decide whether to authorize continuation, finally leaving the task of verifying signature and compliance before actual entry into the cluster to the deployment admission control, managed by Kyverno or OPA Gatekeeper.

The GitOps approach ensures that compliance is repeatable. Policies live in a versioned repository, every change goes through pull requests and reviews, every decision leaves a signed trace. This is exactly the level of rigor required for products that the CRA classifies as critical: container runtimes and hypervisors fall under Annex III as Class II high-risk products¹¹, subject to mandatory audit by independent certification bodies. The reference architectural model for setting up these controls is described in the CNCF white paper on cloud-native security, which provides the high-level framework on which to build concrete policies.

The most delicate operational trade-off is between blocking gates and informative gates. Blocking every single vulnerability stops delivery and pushes teams to bypass controls; only informing, without blocking, nullifies compliance because no one acts on the reports. The strategy we adopt is selective blocking by severity and context: critical vulnerabilities with known exploits and unsigned artifacts are blocked, others are reported with remediation SLAs. Platform engineering reduces the cognitive load by providing pre-configured pipelines that make compliance the default state.

Why automation does not transfer CRA legal liability?

Automating scanners and policies in pipelines does not shift legal responsibility from the manufacturer to the tool. The CRA attributes responsibility to whoever places the product on the market: even if a pipeline performs the check, it is the company that answers for vulnerabilities and risks sanctions.

The regulatory principle establishes that the manufacturer remains responsible for compliance even when the control is delegated to an automatic system or an AI model. The sanctions, defined in Article 64, make the risk concrete, up to 15 million euros or 2.5% of global annual turnover, whichever is higher, in addition to the possibility for authorities to impose the withdrawal of the product from the market¹². Understanding if your software falls into the most severe risk classes is the prerequisite for any automation strategy. We have dedicated an analysis to CRA risk classes and manufacturer responsibilities that frames where each product falls.

The architectural consequence dictates that automation must be auditable. It is not enough for the pipeline to perform the checks; it must produce immutable and traceable evidence that demonstrates due diligence in the event of an incident or audit. In enterprise projects, this means keeping:

• Versioned SBOMs for each release, traceable to the commit that generated them.
• Archived scan reports with timestamps and reference CVE databases.
• Sigstore signatures and transparency logs attesting to the provenance of artifacts.
• Signed policy decision logs documenting what was blocked and why.

This evidence allows responding to CRA obligations to notify exploited vulnerabilities within the tight timeframes provided by the regulation, demonstrating that you have acted with diligence.

There is also the theme of shared responsibility in a cloud-native environment, where those who develop the code, those who manage the platform, and those who operate in production coexist. Policy as code and admission control define explicit boundaries between these roles and reduce human error, because the constraint is codified and not entrusted to the discipline of the individual. Our CTO, Paolo Mainardi¹³, is an Advisory Member of Linux Foundation Europe and has contributed to the #FixTheCRA initiative, created to reconcile the security requirements of the regulation with the sustainability of the open-source ecosystem¹⁴.

Conclusion

Automated CRA compliance is not a cost, but a quality accelerator that reduces technical debt and lowers the mean time to remediation of vulnerabilities. The common thread requires adequate tools, native integration into pipelines, and auditable evidence. Detaching one of these three elements compromises the entire system.

If your pipeline runs scanners but does not keep signed and versioned evidence, you are not ready for a CRA audit, regardless of how many tools you have integrated. The difference between automation that protects the company and one that only generates noise lies in the persistent traceability of every decision.

Translating these criteria into a reliable technical strategy requires cross-functional skills across cloud native, security, and compliance, a profile we have summarized in the requirements for choosing a technology partner in the cloud-native transition. If you want to evaluate the maturity of your pipeline against CRA obligations, the SparkFabrik team can help you identify architectural gaps before the 2027 deadlines: discover our supply chain security services or contact our experts.

In the next article in the series, dedicated to the distinction between open-source contributors and commercial manufacturers according to the CRA, we will analyze how responsibility is distributed along the component chain and why the difference between contributing and placing on the market radically changes obligations: from the estimated 90% of products in self-assessment to scenarios where a single upstream contributor risks being called to answer for a completely unexpected use of their code¹⁵.

Notes and sources

Security teams relying on quarterly scans and spreadsheets cannot physically meet the 24-hour notification window for active exploits. Risk management automation is now a legal requirement for operating in the European market.

The Cyber Resilience Act (CRA), a natural evolution of the directives born with the EU Cybersecurity Act, ties access to the European market to strict security standards¹. By placing server operating systems and container runtimes in Class II of critical products², the regulation subjects the core components of modern infrastructure to the strictest controls provided by law.

The 2024 OSSRA report highlights how 91% of repositories contain components that are at least 10 versions behind³. Tracking vulnerabilities across these volumes to maintain CE marking exceeds the capabilities of any human team.

Implementing continuous vulnerability management driven by AI allows machine learning systems to handle massive data analysis. Integrating machine learning into workflows shifts security control from an isolated event to a process metric, provided the reliability of the decision-making models used is precisely measured.

Why reactive vulnerability management is no longer enough for the Cyber Resilience Act

Reactive vulnerability management fails under the Cyber Resilience Act because the legislation mandates the notification of active exploits within 24 hours for the entire product lifecycle. Traditional periodic scans generate unacceptable delays, exposing the company to fines of up to 15 million euros and sales bans.

Article 14 of the regulation defines inflexible reporting timelines to ENISA⁴ and national CSIRTs. The European legislator has eliminated the distinction between development and maintenance, forcing manufacturers to ensure constant security standards even years after the initial release.

To frame the regulatory perimeter and understand which responsibilities fall on the manufacturer, we have already explained how to identify the risk classes provided by the CRA in a dedicated article of this series.

The economic risk directly impacts business continuity, as national authorities gain the power to impose product withdrawals and bans on placement in the European market⁵. Added to this are fines for non-compliance with essential security requirements reaching up to 15 million euros or 2.5% of the company’s total global annual turnover, whichever is higher.

Faced with thousands of software dependencies layered over time, the volume of CVEs (Common Vulnerabilities and Exposures) to be manually evaluated grows faster than remediation capacity. The backlog accumulates, extending the MTTR (Mean Time To Remediation) —the average time between the discovery of a vulnerability and its resolution. A quarterly scan leaves weeks uncovered where an active exploit can hit systems. Manual prioritization is also subject to cognitive biases, leading analysts to overestimate known CVEs and underestimate contextual ones. Without a map of real exposure, every vulnerability seems equally urgent, and reconstructing an incident’s causal chain in a few hours becomes mathematically impossible.

How AI transforms vulnerability management into a continuous process

Artificial intelligence transforms vulnerability management by automating prioritization and reducing false positives. By correlating CVEs with actual code exposure in production, AI allows teams to focus on real risks, slashing the mean time to resolution and ensuring compliance with regulatory notification windows.

In our approach to complex fintech projects in 2023, managing over 400 repositories and thousands of historical CVEs, the integration of automation and contextual correlation generated measurable efficiency metrics. In our experience, starting from a baseline of 14 days, we believe the structured flow slashed the MTTR to less than 48 hours, with an estimated reduction of around 80%. This result stems from a process that crosses dependency identification, vulnerability databases, and continuous validation with selective blocking. The technological foundation lies in software lifecycle automation, a field we explored by analyzing how artificial intelligence is redesigning DevOps pipelines and security processes.

The AI-driven flow operates in four sequential phases:

1. Ingestion: continuous collection of SBOMs, logs, and runtime data from pipelines and production environments.
2. Correlation: automatic cross-referencing of components with vulnerability databases and active exploit indicators.
3. Prioritization: ranking of CVEs based on real impact on the product, not just theoretical severity.
4. Notification: generation of the audit trail needed to comply with ENISA reporting timelines.

Intelligent prioritization and noise reduction

Contextual prioritization distinguishes a useful alert from background noise. AI correlates each CVE with the real exposure context, verifying if the asset is in production, if the vulnerable code is actually called by the application flow, and if an active exploit is circulating.

In the same 2023 fintech program, where scanners on 400 repositories produced an average of over a thousand reports per week, contextual correlation cut the volume of alerts requiring human intervention by about two-thirds. Instead of manually sorting through hundreds of undifferentiated reports, the team intervened exclusively on flaws with a real impact on the product subject to CE marking.

Continuous monitoring and detection of anomalies

Anomaly detection models observe runtime behaviors and signal deviations from a learned baseline. This mechanism anticipates the exploitation of vulnerabilities not yet cataloged, shifting the security posture from reactive to proactive.

The DORA regulation⁶, relevant for those operating in the financial sector, presents similar dynamics. Both directives push toward continuous monitoring of digital risk, but with a different focus, as we analyzed when examining the impact of NIS2 and DORA on cloud-native cybersecurity.

The CRA looks at the product, while DORA looks at the entity. A financial company that develops software often falls under both, making continuous monitoring a double legal obligation.

What AI observability means and why it matters for compliance

AI observability consists of constantly monitoring data quality, model drift, and the reliability of decision-making outputs. For regulatory compliance, overseeing intelligent systems is mandatory: a degraded model generating false negatives exposes the product to undetected vulnerabilities, compromising CE marking.

Artificial intelligence observability ensures that automation tools do not introduce new blind spots. A system that misclassifies vulnerabilities causes active harm by ignoring threats it should block. ML observability thus becomes an integral part of the security chain. Introducing AI models into defensive processes requires transparency and risk management, as the manufacturer must account for automated decisions to maintain compliance.

Monitoring the models that monitor security

Three signals define the health of a model applied to security: data quality monitoring, drift detection, and output explainability. Drift is particularly insidious because it acts silently. A model trained on a certain threat profile degrades as attack types evolve, without generating obvious errors in traditional logs.

The category of data observability, represented on the market by tools like IBM Databand⁷, was born specifically to oversee the data pipelines that feed models. To delve deeper into control strategies for probabilistic systems, we described how to govern and monitor AI agents in production, a topic that applies with the same logic to security tools.

Guardrails and traceability of automated decisions

Compliance requires documented proof of how a specific vulnerability is classified and managed. An audit trail of AI decisions and guardrails are needed to prevent unverified automatic actions, especially when the outcome influences the validity of the CE marking.

Our security-by-design approach establishes that automation must empower teams while maintaining human control over critical decisions. It is necessary to monitor the quality of the data entering the model and measure drift relative to the training baseline. It becomes equally important to evaluate the decision latency between detection and classification, keeping the false negative rate under strict control.

Implementing continuous vulnerability management: what is really needed

Implementation requires a structured path: gaining total visibility into dependencies via SBOM, automating risk prioritization, and continuously monitoring AI models. This approach transforms regulatory compliance into a process integrated into DevSecOps pipelines, avoiding the bottlenecks typical of manual checks.

The first phase starts with the dependency inventory. We explored this aspect by explaining how the Software Bill of Materials maps supply chain risks under the CRA: without an updated SBOM, any automation works on incomplete data. Management risks require immediate attention, as blindly relying on AI without human supervision turns a mitigation tool into a single point of failure. This is followed by insufficient training data quality and friction in integration with existing DevSecOps pipelines. In these flows, security gates must block non-compliant releases without paralyzing development speed.

The reconciliation between CRA requirements and operational sustainability sees our team directly involved. Our CTO Paolo Mainardi is an Advisory Member of Linux Foundation Europe⁸ and supported the #FixTheCRA initiative, created to prevent the regulation from penalizing the open-source ecosystem⁹. Foundations like the Apache Software Foundation and the Eclipse Foundation expressed strong criticism of the initial text, later welcoming the late 2023 amendments¹⁰.

Measuring the real maturity of the process requires precise indicators:

• Updated and versioned dependency inventory (SBOM).

• Measurement of MTTR as an actual process metric and not just a simple estimate.

• CI/CD pipelines with active and blocking security gates.

• Continuous monitoring of the AI models used.

• Notification process capable of operating within strict regulatory timelines.

The absence of even one of these requirements leaves the exposure to legal risk open.

Conclusion and next steps

Automating vulnerability management through AI transforms compliance with the Cyber Resilience Act into a sustainable process, eliminating the race against time with every new CVE.

Fines of up to 15 million euros clearly define the business risk. At the same time, the 80% reduction in mean time to resolution (MTTR) quantifies the return on technical investment.

Assessing your process maturity requires inventory analysis, MTTR measurement, and verification of the AI models in use. To turn this assessment into an operational strategy across the entire chain, our specialists can accompany you in securing your software supply chain.

The next article in the series addresses the architectural and strategic criteria for choosing and implementing software solutions capable of maintaining CE compliance throughout the product lifecycle, providing agnostic guidelines for tool selection.

Notes and sources

At the end of every PHPDay edition, a ritual repeats: someone, somewhere, is writing yet another obituary for the language. And every time we return home with the same conviction: PHP is not dead this time either. This isn’t a consolatory joke. It’s what was seen on stage at the 2026 edition: a release process governed with discipline, agentic frameworks in full competition, real-time pushed as far as QUIC, and a community that consciously decides when to break its own past.

The narrative of PHP’s decline compared to Python and Node.js has dragged on for years. It is convenient because it relies on popularity rankings, and fragile because it confuses fashion with maturity. The vitality of a language is not measured by how many new recruits choose it for their first project, but by the quality of the process through which it evolves and the solidity of the tools surrounding it.

PHPDay 2026¹ was exactly this: a snapshot of an adult ecosystem. Let’s go through the talks that tell this story best, starting with the most uncomfortable question of all: how does a living language decide to evolve?

A language that evolves is a language that decides how to break its past

The first proof of maturity is not a feature. It’s a process.

In “Shipping PHP 8.5”, Volker, release manager for PHP 8.5², did something rare for a technical talk: he spoke less about the language’s new features and more about how it is decided what goes into a release and how it is “shipped.” The new native extension for URI management compliant with RFC 3986³, for example, does not stem from an individual choice but from a public path of proposal, discussion, and voting. Understanding this mechanism matters more than memorizing a single function: it says that PHP is not “managed” by a vendor, but deliberated by a community.

That mechanism became palpable in the “Panel: the future of PHP”, where Volker, Gary, Gina, Derick, and Sara discussed proposals that are still open: generics with type erasure, scope functions, and pattern matching. One may or may not agree with every single RFC, but the panel’s message was unmistakable: PHP evolves thanks to its community, and the invitation to join the mailing list and contribute was not rhetoric; it was an operational request.

The closing keynote by Gina, “Progress lies within Backwards Compatibility breaks”, focused on the truth we often prefer to ignore: breaking backwards compatibility is the necessary and inevitable price of progress. Gina used analogies with other sectors—rail transport, electricity—which sometimes rebuild entire infrastructures to simplify integrations and reduce maintenance costs in the long run. Treating breaking changes as accidents means condemning oneself to technical debt; treating them as investments means designing to last.

Those who manage PHP in production know this dynamic well. When Drupal 10⁴ was released on December 14, 2022, adopting Symfony 6⁵ and raising the minimum requirement to PHP 8.1⁶, the entire ecosystem had to adapt. It is a real case of how language evolution propagates across major CMSs, a topic we explore further when talking about the new era of content management with Drupal CMS. And right here lies the difference between suffering a breaking change and governing it: tools like Rector for automatic refactoring, PHPStan, and Psalm for static analysis allow for identifying deprecated code before migration, transforming a traumatic jump into a planned path.

A language that redesigns itself does not do so in a vacuum. It does so to stay on the hottest fronts of contemporary software.

PHP on the new frontiers: agentic AI and real-time communication

The PHP ecosystem is moving rapidly on the ground of agentic frameworks. An agentic framework, for those who don’t work with AI daily, is the infrastructure that allows a Large Language Model not just to respond, but to perform actions: invoke tools, consult sources, and orchestrate multiple steps toward a goal.

In the talk “The PHP AI Battleground: Choosing Your Agentic Framework”, our own Luca Lusso, lead developer at SparkFabrik, compared three promising PHP frameworks for agentic workflows: Laravel AI, Symfony AI, and Neuron AI. Each has pros and cons, and none is the universal answer. Laravel AI integrates naturally with those already living in the Laravel ecosystem; Symfony AI brings Symfony’s architectural rigor to the agent domain; Neuron AI was born leaner and more focused. The choice depends on the stack already in use and the workflow requirements. (We explore the Neuron AI framework further in our dedicated webinar “Building AI agents in PHP with Neuron AI”)

Some read this plurality as fragmentation. We read it the opposite way: three competing frameworks are the sign of a buzzing ecosystem that is choosing its own direction instead of being subjected to it. The critical point comes in the next phase: bringing an agent into production means governing a probabilistic system, and this requires dedicated observability practices, such as those we describe when talking about AgentOps, from monitoring token consumption to detecting hallucinations.

The same vitality was seen in real-time. In “PHP’s Real-time Toolkit: All the Ways to Notify Clients”, Grzegorz reviewed all the ways to push data from server to client: from old polling to modern patterns like WebSocket and Server-Sent Events (SSE), pointing to WebTransport based on QUIC⁷ over HTTP/3 as the future. In his presentation, he cited Mercure, presented as a solution based on the Server-Sent Events mechanism, and two more structured alternatives:

• Centrifugo: a platform that supports many protocols, scales well, and handles automatic fallbacks, at the cost of having to run a separate server.

• Nchan: an Nginx module conceptually similar to Centrifugo, but significantly more scalable.

Here too, variety is not dispersion. It is an ecosystem offering the right tool for every scale and infrastructure constraint.

Innovation without solidity remains fragile. The true maturity of PHP in 2026 is seen in the less flashy engineering details.

Maturity is in the details: data, serialization, and resilience

What makes a language suitable for production are not the surface features. It is the ability to handle data at volume, performance, and errors with discipline. PHPDay 2026 dedicated some of the densest talks to these themes—the ones that never make the headlines.

It starts with raw data. In “Data Processing in PHP”, Norbert showed how to extract and process large volumes of data efficiently and economically, starting from native PHP functions for handling a simple CSV file up to complete ETL processes built with flow-php, the tool he developed. The message: PHP handles serious data loads if you know how to structure the flow.

Then there is the speed problem. Michelle, in “Advanced Serializing in PHP: Speed it up!”, compared different serialization techniques starting from a counterintuitive fact: the Symfony Serializer is the most powerful but also the slowest because it uses reflection to access object state at runtime. The solution is to move complexity to code time, generating fast PHP code, previously with liip/serializer and today with its successor rebuy-oss/serializer. Michelle’s team went further, building a PHP-to-Go converter to execute the serialization phase in Go and squeeze out even more speed. It is the kind of engineering that is done only when a language is already in production on systems that matter.

Finally, resilience. In “Mastering Failures: Building Resilient PHP/Symfony Apps with Domain-Driven Exceptions”, Stephane taught the correct patterns for domain exceptions in Domain-Driven Design architectures: don’t throw generic exceptions, don’t parse error messages to understand what happened, define a specific exception for every real domain problem. His sharpest advice:

Don’t throw a NotFoundHttpException inside a domain, because the same code might also run in a CLI application.

It is a detail that separates a toy project from an enterprise system, the same decoupling rigor we find in the choices between monolith and microservices. These are the themes on which it is measured whether a community is adult. And PHP, here, is.

But isn’t PHP in decline compared to Python and Node? The factor that rankings ignore

Let’s face the strongest objection without running away. It’s true: public perception sees PHP in decline. New developers gravitate toward JavaScript and Python, AI and data science have made Python the default stack for entire categories of projects, and popularity rankings tell a downward story. Ignoring this would be dishonest.

Yet rankings measure fashion, not maturity. The numbers tell another story: PHP remains the server-side language of about 77% of websites with a detectable backend, and WordPress⁸ alone powers over 43% of the web. Adding Magento in e-commerce, Symfony and Laravel in enterprise, and Drupal in complex portals, the presumed end takes on rather lively contours.

The real point isn’t even these numbers. It’s the fundamentals.

In “Packets, Protocols and PHP: Networking Fundamentals for Developers”, Jessica led a tour of network layers, from Application to Physical in the OSI model, with the truth every sysadmin knows: “it’s always DNS (or BGP, or more often, both).” Networking fundamentals don’t go out of style and are independent of the language. Those who master them are better engineers, whatever stack they choose.

The solidity of an ecosystem can be read in its tooling. Derick, creator of Xdebug, in “Better Debugging With Xdebug” showed live the new features of Xdebug 3.5⁹: Native Path Mapping, out of band signalling, automatic line discovery, and more, as detailed in the official announcement. A debugging tool so well-maintained is proof of a community that invests in quality, not just features. It is the same commitment that as a Drupal Certified Partner Gold we bring to the maintenance of WebProfiler, the debug module for Drupal with over 1,000 active installations.

Judgment makes the difference. Gary, in “It Depends”, conducted an interactive session on the critical decisions every developer faces every day: monolith or microservices, hand-written or AI-generated code, opinionated or non-opinionated frameworks. The conclusion, honest and disarming, is the title itself: in the end, it depends. Maturity is not a dogma; it is contextual judgment.

Finally, the people. Carolina, a psychologist, held “Communication for devs: explaining complex ideas simply”, an interactive keynote in which we tried to improve our ability to explain: tell a story to the person sitting next to you, use an analogy, frame ideas from the listener’s perspective. The most important secret, she said, is to breathe.

Rankings measure popularity. An adult language is measured by its fundamentals, its tooling, and its people. And it is exactly on these axes that PHP, in 2026, is rock solid.

What remains of PHPDay 2026

“PHP is not dead” is not a defensive reassurance. It is the observation of a fact: a language capable of consciously breaking its own past to progress, as Gina argued, of competing on agentic frameworks and real-time, and at the same time of cultivating its fundamentals with discipline, is a deeply living language.

The real risk is not the end of PHP. It is that the community stops participating. The invitation that emerged from the panel—to join the mailing list, discuss RFCs, contribute—was not a ceremonial detail: it is the very engine that keeps the language alive.

From our experience with enterprise PHP codebases in production, this reading is the same one we see confirmed every day in the field. The right question, coming out of PHPDay 2026, is not “Is PHP dead?”. It is: do we have the technical and human maturity to use it as it deserves?

Notes and sources

A provider claiming to be “secure” and one displaying an accredited certificate with a verifiable public number seem to be saying the same thing. They are not. The first asks you to trust them; the second allows you to verify. During due diligence, this is the only distinction that truly protects the decision-maker.

That’s why it’s useful to clarify one point immediately: regarding certifications and regulatory compliance, the four pillars we’re discussing—security, sustainability, open source, and accessibility—are not initiatives that started yesterday. They are processes we have been carrying out for years and which now have external proof instead of an internal statement. SparkFabrik’s ISO certifications and scientific validations make this commitment inspectable. All evidence is gathered on the page bringing these four commitments together, designed specifically so that anyone can check instead of taking our word for it.

These are four different lenses focused on the same idea. The first, where verification is most codified, is security.

Why SparkFabrik’s ISO certifications are fundamental for security

SparkFabrik’s ISO certifications (27001:2022, 27017:2015, 27018:2025) guarantee that information security and cloud data are managed through documented processes verified by third parties. Valid from 2026 to 2029 (certificate ITA-10325, issued by Scandinavian Certification, accredited by Norwegian Accreditation), they ensure risk management, operational continuity, and structured support for GDPR compliance.

An ISO certification doesn’t certify a product, but a management system. It’s a distinction that changes everything, and one that many corporate communications often blur.

When an accredited body issues an ISO/IEC 27001:2022, it isn’t saying that a single piece of software is secure at a given moment. It is attesting that there is a documented and repeatable process for managing information security: how risks are identified, how incidents are handled, and how continuity is guaranteed. Security, in other words, is not an occasional behavior but a verified method.

SparkFabrik has achieved three complementary certifications, which together cover the levels on which a client exposes their data when entrusting a project to an external partner:

• ISO/IEC 27001:2022, for information security;

• ISO/IEC 27017:2015, for cloud-specific security;

• ISO/IEC 27018:2025, for personal data protection in the cloud.

For those evaluating a provider, this translates into three concrete guarantees: documented risk management, service continuity even in the event of an incident, and structured support for GDPR compliance—the European regulation that imposes specific obligations on personal data processing. A certified management system doesn’t make compliance automatic, but it provides the framework on which to build it.

A crucial, often overlooked detail concerns accreditation. Our certifications were issued by an accredited body, with a certificate identified by a unique code and a precise validity period. Those references are not decoration.

A statement on a website cannot be checked. A certificate number issued by an accredited body can.

Anyone—a security officer during evaluation or a procurement manager—can trace back to the accrediting body and verify that the certification is real and active. This is the substance: not having written “we are secure,” but having made that statement verifiable by an independent third party. The technical and methodological meaning of relying on a partner with ISO-certified management systems lies entirely in this possibility of inspection.

Security is verified through periodic audits. But there is a field where verification is even more stringent because the numbers don’t end up in a confidential report: they end up on a public registry, validated using a scientific method.

How to recognize a real corporate sustainability commitment

A real commitment is recognized by independent scientific validation and presence on public registries. SparkFabrik’s emission reduction targets are validated by the Science Based Targets initiative (SBTi ID 40017722), classified as 1.5°C-aligned, with a 2024 base year and a 2030 target. This makes the commitment measurable and verifiable.

In sustainability, greenwashing is the rule, not the exception. “Carbon neutral,” “green,” “zero impact” are statements that cost nothing to say and that almost no one can disprove because a point of comparison is missing.

The difference between a real commitment and a declared one boils down to a single element: validation by an independent scientific body and presence on a searchable public registry. To credibly evaluate the sustainability of a software company, there are no shortcuts alternative to this.

SparkFabrik’s emission reduction targets are validated by the Science Based Targets initiative through the simplified pathway dedicated to SMEs, and are classified as 1.5°C-aligned—consistent with the Paris Agreement’s goal of limiting global warming to 1.5°C. The base year is 2024, the target year is 2030, and the public identifier is SBTi ID 40017722.

The targets, in official wording, are these: Scope 1 emissions at zero until 2030; Scope 2 absolute reduction of 42% by 2030 from the 2024 base year; Scope 3 measure and reduce.

There is one figure that, more than any statement, tells the story of what serious measurement means. 97% of our total emissions fall under Scope 3, the hardest category to control because it includes indirect activities. The main items are:

• commuting and remote work (38%);

• business travel (22%);

• IT purchases (20%);

• capital goods (19%).

Declaring that 97% is uncomfortable. It means publicly admitting that the largest part of your impact escapes direct control. It is the exact opposite of greenwashing, which tends to showcase easy numbers and hide difficult ones.

Submitting to a scientific methodology with a base year, target year, and a public ID means accepting being measured. And being able to fail publicly.

This is what gives value to the number. Anyone can check ID 40017722 on the official registry of companies that have taken a validated climate commitment and compare targets with progress. The same applies to the full overview of the journey, documented on the page dedicated to our reduction strategy. A number that can be disproven by a third party is more reliable than a slogan that no one can contest.

At this point, a skeptical reader has every right to object. Aren’t certifications and validations ultimately just “badges” to show off in tenders? It’s a serious objection, and it deserves a serious answer.

Are certifications just marketing badges?

No, if supported by continuous verification and inspectable contributions. A failed ISO audit results in the revocation of the certificate, proving that processes must be maintained. Furthermore, seventeen years of public open source contributions (since 2008) offer a radical and non-falsifiable transparency that no marketing badge can replicate.

Let’s take it in its strongest version, without softening it. Many companies collect certifications like marketing trophies. They get them once, put the logo on their homepage, and meanwhile, the actual processes remain identical to before. The certificate becomes decoration, not a guarantee. The annual audit turns into a formal exercise to be passed with minimum effort.

This criticism is legitimate. A certification obtained and then ignored is indeed just a badge, and pretending otherwise would be dishonest. Maintaining certification requires rigorous periodic audits: if serious non-conformities emerge during these checks and processes are not followed, the accredited body revokes the certificate. It is not a goal achieved forever, but a continuous examination.

However, a further proof of seriousness is needed—one that cannot be obtained as a one-off, cannot be bought, and cannot be faked over time. That proof exists, and it is verifiable public contribution. Open source code is the most transparent form of reliability, because every commit is dated, public, and traceable by anyone, forever. There is no way to simulate it retroactively.

SparkFabrik has been making public open source contributions since 2008, following a precise principle: build it, don’t just use it. It’s a substantial difference compared to those who adopt free software only to save on licenses. This choice is reflected in concrete technical credentials: we are a Drupal Certified Partner Gold, Kubernetes Certified Service Provider, and members of CNCF, Linux Foundation Europe, and OpenSSF —the foundations that govern cloud-native standards and open source software security. The modules we publish are inspectable by anyone on the official SparkFabrik profile on drupal.org.

There’s more, and it directly touches on the security we mentioned at the beginning. Participation in OpenSSF and the risk mapping of software dependencies—at the heart of the software supply chain security best practices we have documented—respond to the same logic of verifiable transparency required by regulations like the Cyber Resilience Act, which from 2027 will impose stringent and documented security requirements for all software placed on the European market.

And here is the heart of the thesis. An ISO certification and seventeen years of public commits demonstrate the same thing from two opposite directions:

• certification is a top-down verification, where a third party checks your processes;

• open source is a bottom-up verification, where anyone can inspect your work, line by line.

Together, they make the “it’s just a badge” objection unsustainable. Because you don’t keep a badge public for seventeen years. The full verification of this approach is gathered on the page documenting our work in free software.

There remains one pillar that tests this philosophy exactly where companies cheat the most: accessibility, too often added at the end.

What does it mean to treat accessibility as a project requirement?

It means integrating accessibility from day one of design and development, respecting WCAG 2.2 AA and EN 301 549 standards. This methodological approach guarantees real compliance with the European Accessibility Act (in force from June 2025), avoiding makeshift and superficial solutions applied just before launch.

Imagine a site made “accessible” the week before launch, with a script added on top of the site that promises to fix everything automatically. It’s the digital equivalent of a company collecting badges: a patch applied over work designed without any attention to those who navigate with a screen reader or without using a mouse.

Accessibility is the ultimate testing ground for the thesis, because it’s the pillar where the gap between “declared” and “done” is most visible to the naked eye. A poorly built page doesn’t become accessible by applying an external layer: only the appearance for automatic scanning tools changes, not the actual experience of people.

At SparkFabrik, we treat accessibility as an initial project requirement, not a final addition. Design complies with the WCAG 2.2 AA standard, the international reference for web content guidelines, and the European EN 301 549 standard, in line with the requirements of the European Accessibility Act.

It’s worth explaining what these acronyms mean for those who don’t handle them every day. The European Accessibility Act is the European directive that, starting from June 2025, obliges a wide range of digital products and services—from e-commerce to banking services—to be accessible to people with disabilities. EN 301 549 is the technical standard that translates that obligation into verifiable requirements, and in turn, relies on WCAG. These are not recommendations: they are criteria against which a service can be judged compliant or non-compliant.

Designing according to these standards from the beginning is the equivalent of public commits: a method, not a patch. It means that semantic structure, color contrasts, keyboard navigation, and focus management are design decisions made on day one, not corrections chased at the last minute. The regulatory context that makes this approach no longer postponable is reconstructed in the analysis of the European Accessibility Act deadlines.

Thus the circle closes. The four pillars are four ways of making the same choice: making work verifiable rather than simply declared. An ISO audit checks processes. An SBTi registry checks emissions. A public repository checks code. An accessibility standard checks the interface. In each case, someone external can verify what we claim.

The thread connecting audits, emissions, code, and interfaces

Third-party verifiability is not bureaucracy. It is how trust stops being a matter of a given word and becomes measurable.

For those selecting a technology partner, the practical criterion is simple and can be applied to any provider. Ask for the certificate number. Ask for the ID on the public registry. Ask for the link to the repositories. If the answer is a marketing page instead of a verifiable reference, the difference between those who declare and those who prove has already emerged, even before signing a contract.

The bar for what a client can legitimately expect is rising. It’s good for the whole industry because it narrows the space where simply stating something is enough to be believed. This movement is part of a broader methodological vision, the same one that leads us to support our ISO 27001, 27017, and 27018 certifications with verifiable evidence rather than statements.

The meaning of our work on the four pillars is exactly this: transforming daily care into something a client can check without having to take our word for it. All evidence is gathered and available on the page bringing our commitments together.

The entry into force of the Cyber Resilience Act¹ (CRA) imposes new responsibilities on European C-levels and technical decision-makers: software security is no longer just an engineering best practice, but a strict legal requirement for market access. The legislator has drawn a clear line, establishing that opacity within the supply chain is no longer an acceptable business risk. Those who place digital products on the single market are now directly responsible for vulnerabilities present in the code, including those originating from third-party libraries.

Faced with these directives, the Software Bill of Materials (SBOM) emerges as the fundamental and mandatory operational tool for obtaining the CE marking. Without an exact mapping of what makes up the software, demonstrating compliance is impossible. This article explores methodologies for exhaustively mapping dependencies, quantifying technical debt accumulated in repositories, and preparing corporate infrastructure for new compliance standards. Moving from a reactive approach to structured governance requires the native integration of security into software development and distribution processes². This evolution ensures total visibility into the foundations of your product, allowing you to release secure updates without suffering regulatory blocks.

Why the Cyber Resilience Act makes the SBOM a business constraint

European legislation transfers the legal responsibility for vulnerabilities directly to those who distribute the product. Without an updated inventory of dependencies, maintaining the CE marking becomes impossible. This failure translates into an immediate block on sales and exposure to sanctions calculated on the company’s global turnover.

The transition imposed by the new European regulation consists of abandoning traditional reactive patching in favor of a structural approach based on Security-by-design³. Until a few years ago, the integration of open source or third-party components took place with minimal checks, implicitly delegating security to external maintainers. Today, the CRA establishes that the burden of proof falls on the manufacturing company.

The latter must ensure that every line of packaged and distributed code is traceable, secure, and free of known vulnerabilities. This European regulatory orientation aligns with a global movement that began in the United States with Executive Order 14028⁴, ⁵. The provision, known as the Executive Order on Improving the Nation’s Cybersecurity⁶, mandated the use of software bills of materials for anyone providing digital solutions to federal agencies.

A careful analysis of legal responsibilities shows that compliance is no longer an operational delegation for development teams, but a fiduciary mandate for the corporate board. Integrating code of unknown origin and composition is equivalent to placing a physical product on the market without knowing its manufacturing materials. This responsibility is fully integrated into modern risk management and ESG governance strategies, where digital transparency is a fundamental pillar.

The absence of rigorous governance over dependencies exposes the organization to severe risks. The first obstacle is the blocking of commercialization due to the immediate invalidation of the CE marking throughout the European Economic Area. Added to this are direct financial sanctions, calculated as a percentage of the company’s global turnover, in the event of incidents resulting from negligence in mapping. Finally, there is the risk of catastrophic reputational damage and the loss of trust from customers and investors, as demonstrated by recent supply chain attacks on official packages linked to large vendors. Without total visibility, affected companies do not know they are executing hostile code, replicating on a smaller scale the systemic damage already observed during the SolarWinds case⁷.

What does SBOM mean and how does it differ from a traditional bill of materials?

An SBOM is the formal and structured inventory of all components, libraries, and dependencies used to build a software application. Unlike a traditional bill of materials, it includes specific versions, usage licenses, hierarchical relationships between packages, and cryptographic signatures necessary to ensure the integrity of the entire supply chain.

To understand the value of this tool, an analogy with the manufacturing industry is useful. When an automotive company assembles an engine, it tracks exactly the origin, batch, and specifications of every single screw; if a supplier reports a metallurgical defect, the parent company knows exactly which vehicles to recall. Software engineering, for decades, has operated by assembling libraries without maintaining this level of traceability. In traditional PLM (Product Lifecycle Management) systems, software is often treated within an EBOM⁸ (Engineering Bill of Materials) or an MBOM⁹ (Manufacturing Bill of Materials) as a single black-box component, a monolithic aggregate devoid of internal details.

The software bill of materials breaks this opacity. However, a simple text list of packages is not sufficient for the automation required by modern regulations. For this reason, the industry has developed specific standards. CycloneDX¹⁰ and SPDX¹¹ are the standardized formats used to document information about software components within an SBOM. These formats, also recommended by CISA guidelines¹², allow machines to read the inventory and automatically cross-reference it with global threat databases, such as the National Vulnerability Database¹³.

For enterprise organizations, maintaining total supply chain visibility through a structured component inventory is the only scalable method for managing application complexity.

The substantial differences between a generic bill of materials and a standardized SBOM emerge on three fronts. Regarding resolution depth, the generic bill lists only first-level libraries, while the standardized SBOM maps the entire hierarchical tree. For license management, the modern inventory automatically includes legal metadata to prevent copyright violations derived from restrictive open source code. Finally, cryptographic verification integrates unique hashes for each component, ensuring that the scanned library is exactly the one compiled into the final artifact.

How to map dependencies to mitigate supply chain risk?

Mapping dependencies requires the integration of compositional analysis tools directly into development pipelines, tracking both directly imported packages and transitive dependencies. This continuous approach identifies vulnerabilities before release into production, transforming the inventory from a static document into a dynamic and automated security safeguard.

The greatest risk for CTOs does not lie in internally written code, and often not even in libraries imported directly by developers. The real blind spot is constituted by transitive dependencies: code written by third parties that in turn calls other third-party code, creating a deep and invisible chain. As pointed out by our CTO Paolo Mainardi, organizations have now reached a point of no return in managing software dependencies: ignoring the complexity of this tree means accepting incalculable technical debt. The OSSRA 2024 report reveals that 91% of examined code repositories include components that are 10 or more versions behind.

How can we govern this complexity? Modern software engineering is based on the continuous integration of third-party libraries. This composable approach is correct and necessary to accelerate releases, but it exposes applications to structural fragility if not governed. The weakness of these architectures is demonstrated by a series of recent attacks that have compromised ecosystems considered secure. In the world of development tools, the compromise of the Nx Console extension for VS Code demonstrated how a stolen token on GitHub can distribute malicious code to millions of machines. The Python ecosystem has suffered critical blows on PyPi, where packages linked to the AI stack like LiteLLM were manipulated to steal root keys.

Enterprise infrastructures are not immune either. Red Hat had to manage critical vulnerabilities linked to unauthorized access in its GitHub organizations, while cloud-native platforms like Vercel faced security incidents that threatened frontend deployments. In the PHP ecosystem, targeted attacks hit Laravel Lang packages by injecting credential stealers directly into translation dependencies. These incidents demonstrate that blindly trusting imported code is equivalent to leaving the keys to the infrastructure to strangers.

From our field experience in the enterprise projects we manage, we have found that inventory generation cannot be a manual activity performed at the end of a project. It must become a native process within Continuous Integration (CI) pipelines. Implementing industry standards like Sigstore¹⁴ and OpenSSF to validate OCI artifact integrity ensures that the distributed code corresponds exactly to the scanned code, preventing attacks on package repositories.

The strategic approach for effective mapping is divided into three operational phases:

1. Direct and transitive identification: automated scanning of manifest files (such as package.json or pom.xml) during the build phase to resolve the entire dependency tree, exposing the deepest levels.
2. Cross-referencing with vulnerability databases: real-time comparison of component hashes with threat intelligence feeds, assigning an immediate risk score to every build.
3. Continuous validation and selective blocking: configuration of policy-as-code that automatically interrupts the CI pipeline if the introduction of a library with critical vulnerabilities or unapproved licenses is detected.

What metrics define the ROI of automated management?

The ROI of automated management is measured through a reduction in Mean Time To Remediation (MTTR) of up to 80% during critical incidents and the elimination of hours dedicated to manual audits. Automation transforms compliance from an operational cost into a competitive advantage, accelerating the time-to-market of secure software releases.

The implementation of a software tracking system should not be evaluated solely as an expense linked to regulatory compliance. Automating the generation and analysis of bills of materials significantly reduces the cognitive load on development teams, a cornerstone principle of the Platform Engineering discipline. When developers do not have to worry about manually tracking libraries or managing spreadsheets for licenses, they can focus on writing value-added features. In this context, the operational efficiency derived from adopting cloud-native and DevOps practices acts as a direct growth engine for the entire organization.

The impact on business becomes evident during security crises. When a widespread zero-day vulnerability emerges, as happened with Log4j¹⁵, companies without an automated inventory take weeks to discover where the vulnerable component is running, accumulating remediation costs that easily exceed 100,000 euros per single incident. With an automated system, the query takes a few seconds. Gartner forecasts indicated that by 2025, 60%¹⁶ of organizations¹⁷ would have mandated the use of these structured inventories in their software procurement processes. Today, in 2026, this dynamic has materialized: the request for SBOMs has become a de facto standard in B2B contracts. Furthermore, rigorous industry standards such as PCI DSS 4.0¹⁸ (the evolution of the PCI DSS framework for payment security) explicitly require detailed inventories of software components to maintain certification.

Concrete metrics for evaluating return on investment include:

• Contraction of Mean Time To Remediation (MTTR): moving from weeks of manual investigation to a few minutes for the identification and localization of compromised packages.
• Reduction of security audit hours: total elimination of manual code reviews for verifying open source licenses and obsolete dependencies.
• Acceleration of time-to-market: smoother release pipelines where security checks occur asynchronously, avoiding bottlenecks before deployment to production.

Next steps for continuous compliance

Adapting to European regulatory requirements represents a path of technological maturity that necessarily begins with total visibility into the software infrastructure. The bill of materials for components is not a static document to be archived after release, but a dynamic data set that requires continuous orchestration to reflect the daily evolution of code and global threats. For C-levels, governing this process means protecting business continuity and ensuring uninterrupted market access.

Organizations that intend to implement the frameworks required by the Cyber Resilience Act and protect their digital assets can request a specialized audit or explore our Supply Chain Security services to ensure full compliance.

In the next article in the series, we will examine the use of artificial intelligence to simulate attacks and automate vulnerability reporting within 24 hours, as required by the CRA time windows.

Notes and sources

📌 See also: our dedicated partner status page: Drupal Certified Partner

SparkFabrik is the first Italian company to reach the Gold level of the Drupal Certified Partner program, the recognition with which the Drupal Association certifies companies that contribute to the ecosystem through code, events, and direct financial support.

This is not an honorary title: it requires a verified minimum threshold of contributions, made by the people who work on the project every day, combined with an annual financial fee. It is proof that the work dedicated to the ecosystem already carried weight, even before anyone certified it.

There are decisions that seem tiny on paper, but when looked back upon years later, they weigh like boulders. Looking back at the Drupal.org profiles of Paolo Mainardi and Stefano Mainardi, one detail stands out immediately: they were created almost 18 years ago. At the time, open source was pure digital craftsmanship; the enterprise dynamics of today did not exist. It was code written at night, patches sent to solve a problem that someone else, on the other side of the globe, would encounter the next day.

But this is not the story of just two people. The other founders and several Sparkers have also been active on the platform for nearly twenty years. Back then, joining the Drupal ecosystem seemed like a small decision. From those roots, a company was born, or rather, an evolution. Even before SparkFabrik, there were Twinbit and Agavee, the companies from which we were born ten years ago, which were already true Drupal companies back then.

We did not choose this CMS for market convenience: we trained on Drupal, embracing open source. Today we have achieved Drupal Certified Partner Gold, the first in Italy. But this is not a trophy to put on display. It is the exact snapshot of that journey that began nearly two decades ago.

Beyond the badge: SparkFabrik is the company that contributes the most in Italy

The Drupal Certified Partners program certifies with a badge companies that innovate, advance, and fund the Drupal project ecosystem. These contributions are measured through so-called Contribution Credits. In this sense, these credits mark the boundary between those who merely consume the work of others in the ecosystem and those who take responsibility for it and give value back.

In the words of our CEO, Stefano Mainardi, for us this is not a marketing badge. It is the financial weight we put behind what we have already been doing for nearly two decades with our own hands, our code, and our time. Contribution Days, YouTube interviews with those who built this community. All that persistent and unglamorous work that is needed to keep a shared project running.

Over time, we have grown enormously. Our evolution toward cloud-native paradigms and modern architectures has led us to embrace DevOps and Artificial Intelligence. But open source has remained the underlying philosophy: not just a tool, but a way of working that promotes collaboration, transparency, and knowledge sharing, in Drupal projects as well as in those for development and cloud-native architectures.

A commitment that we also bring to our memberships. We are members of CNCF, Linux Foundation Europe, and OpenSSF, with Paolo Mainardi (CTO) on the LFE Advisory Board. The roots remain there, firmly planted in open code.

Becoming a Drupal Certified Partner is how we add our financial weight to our long-standing craftsmanship. Because open source is free to download, but tremendously expensive to keep alive.

There is another fundamental point. Foundations like the Drupal Association are the only truly neutral ground left. They are the only spaces where vendors, agencies, and individual developers can meet as equals.

Without an independent structure, any open source project would end up swallowed by the commercial interests of a single company. The lack of neutral governance exposes projects to conflicts between parties that have nothing to do with software, as the recent WordPress case and the disaster with WP Engine teaches us.

Financially supporting these foundations is not a strategic move. It is simply the right thing to do, period.

When a company bases its revenue on free software, it has a moral debt to those who keep that software secure and updated. It is not enough to send a patch every now and then. Consistency is required. It is necessary to ensure that the infrastructure hosting the code does not collapse.

The Gold level we have reached certifies exactly this balance: a vital financial contribution combined with a volume of real Contribution Points, generated by the people who work with us every day. It is the measurement of an invisible commitment that becomes tangible.

Among Italian companies, we believe we are the one that has invested in the Drupal community with the most depth and consistency. We have always done so in a healthy and transparent way, faithful to the values of open source.

Stefano Mainardi, CEO SparkFabrik

The value for clients

Our commitment to open source is a guarantee of value for our clients. It is not a facade. Contributing code, participating in international working groups, organizing events: all this keeps us in constant observation of what is happening in technology, in the ecosystem, and in the market. Not out of curiosity, but because that is how we ensure our clients have solid, up-to-date solutions.

A commitment that also takes shape in the sponsorship and active participation in many events in Italy, and in the organization of meetings such as Cloud Native Days Italy and DrupalCamp Italy. We do this because we believe that funding the ecosystems in which we ourselves thrive is a concrete responsibility, and it keeps us close to the communities, the technologies, and what is happening before it becomes mainstream.

Drupal is the platform chosen for enterprise-level digital projects, such as institutional portals, corporate intranets, and digital service platforms.

In these contexts, a reliable technology partner, capable of being the client’s single point of reference, is an advantage of enormous value.

Choosing the Drupal Certified Partner with the highest real contributions in Italy means reducing project risk, having an interlocutor who knows Drupal from the inside, and ensuring continuity over project lifespans that are measured in years.

At SparkFabrik, we believe that the best technology is born from the harmony between deep technical skills and solid human relationships. It is a value firmly rooted in our manifesto and our vision on AI.

We do not want to be a vertical specialist among ten suppliers: we are the single point of reference in the digital journey of those who choose us. Becoming a DCP is a further confirmation of quality for those who choose us.

Sitting at the table: not just using software, but deciding its future

Supporting neutral infrastructure is only the first step. The real impact comes when you decide not to be a passive recipient of technological direction, but to help chart it. It means bringing an Italian voice to the international tables that matter.

As a member of the Linux Foundation Europe Advisory Board, Paolo Mainardi actively participates in strategic discussions on open source, AI, and digital sovereignty at the European level.

In January 2026, he was invited to the Drupal Pivot in Ghent to discuss the future of the project directly with world leaders of agencies, addressing crucial topics such as digital sovereignty and open source for the Public Administration. It was a moment of comparison that confirmed how vital the choice of Drupal for complex corporate ecosystems is for decision-makers. We didn’t go there to listen, but to bring a concrete vision of where technology must go in the coming years.

The recognition of this effort came directly from the top.

“Thank you Stefano Mainardi and the entire team at SparkFabrik for all you do for the Italian Drupal community and for your support in helping the Drupal Association maintain Drupal’s infrastructure and ensure it’s freely available worldwide and to the 8,000+ sites in Italy. I too would like to thank Paolo Mainardi for helping discuss Drupal’s future with agency leaders at Drupal Pivot, Ghent.”

Tim Doyle, CEO Drupal Association

Facts speak louder than intentions. In the last year, we have maintained a very high technical density. We wrote code for the AI Guardrails system of the Drupal AI Initiative, tracked and visible on the official SparkFabrik page on Drupal.org.

On the topic of Drupal alone, we have produced over 40 technical articles, a strategic whitepaper dedicated to Drupal as a DXP, and shared 100+ posts on our social channels. It is a constant commitment to the promotion of the ecosystem, which adds to our production on other topics that concern us closely, such as AI, cloud native, DevOps, and Security.

Our international presence did not stop in Ghent. We gave talks in 3 sessions at DrupalCon Vienna 2025, at Drupal Mountain Camp, and at Drupal Dev Days Leuven, and more recently we were at Drupal Dev Days 2026 in Athens.

We believe enormously in sharing knowledge: we demonstrated this by co-organizing a technical webinar with FreelyGive, and we did it recently with the webinar “Multilingual websites, AI and quality translations in Drupal” together with Lara Translate. This is the difference between using a tool and becoming its custodian.

Rebuilding the Italian community

From global influence, we move to local responsibility. Because we have always cared about supporting the national community. Without commitment and consistency, it risks disappearing: that is why we work every year to strengthen it.

Between 2012 and 2018, we co-organized the DrupalDay together with Bmeme. They were six years of intense physical events, completely self-financed, which built a real connective tissue among Italian developers.

Then there was a long period of stagnation. A silence that did not do justice to the talent and dedication of Italian developers.

But we never stopped completely. Even during this quieter phase, we continued to invest time and budget in other initiatives, for example by hosting the Drupal Global Contribution Day at our headquarters in 2025 and 2026.

A project we care about particularly is our online format Talks on my Machine, our way of sharing knowledge and best practices with the ecosystem, completely free of charge. Two editions were dedicated specifically to Drupal: Drupal X Business (2026) and Drupal: Driving Digital Experiences (2024). Gen AI X Business (2025) and Supply Chain Security (2024) explored other topics dear to us, and by the end of the year, we will return with a new edition dedicated to AI.

However, we knew we needed to look each other in the eye again. We worked to bring back the physical gathering par excellence: first with DrupalCamp Italy 2025 in Rome, bringing 2 sessions to the stage, and now looking toward the next edition of DrupalCamp Italy in Bologna, scheduled for October 22nd. We don’t do it to plant a flag or claim records. We do it because we believe that Italian developers need healthy, transparent spaces free of personal agendas to grow together.

It is hard work, but the responses tell us that we are on the right path. Even the person who created all this, Dries Buytaert, noticed it, recalling the interview we did with him a few years ago (the first time Dries appeared live at an Italian event).

“Thank you so much for all your support and contributions! 💙”

Dries Buytaert, Founder & Project Lead, Drupal

This is our idea of community. A constant presence, which does not hold back when it’s time to roll up our sleeves. Building gathering spaces requires patience. It means managing logistics, communication, and relationships with speakers, taking time away from daily work.

But it is an investment we would make again tomorrow morning, because a healthy ecosystem always gives back a hundred times what it absorbs in terms of energy.

The facts, in summary:

The work continues

Achieving Drupal Certified Partner Gold level, and being the first in Italy to do so, does not represent a finish line. It is rather the validation of a working method. Open source requires care, time, and real investment. It requires companies that choose not to be just spectators.

We will continue to do our part, faithful to the values of open code, working to keep the ecosystems in which we operate neutral and prosperous. The commitment continues, without shortcuts. We will continue to build, line of code after line of code, the community we have always wanted.

We will take the next step together with the community, face to face. See you on October 22nd in Bologna for DrupalCamp Italy: tickets are available and the Call for Papers and Call for Sponsors are open.

The integration of autonomous systems within enterprise architectures requires a profound revision of software engineering practices. AgentOps is the new discipline that governs the lifecycle of autonomous AI agents, a prerequisite for governance, security, and observability, especially for critical flows in enterprise contexts.

Until recently, application monitoring was based on a fundamental assumption: traditional software is deterministic. Given the same input and initial state, a microservice always returns the same output.

The adoption of Large Language Models has shattered this certainty, introducing intrinsically probabilistic components into critical workflows.

This article is aimed at DevOps engineers, tech leads, and platform engineers who are facing an unprecedented operational challenge. It is no longer just about verifying whether a service responds to network requests, but about evaluating whether the decisions made by an autonomous entity are correct, secure, and aligned with business goals. When an AI agent fails, it rarely generates an obvious system error; more often, it produces a semantic hallucination, enters an infinite reasoning loop, or executes unintended API calls.

Traditional monitoring systems, focused on infrastructure metrics such as CPU usage, RAM consumption, or network latency, are completely ineffective against these behavioral anomalies. A Kubernetes pod may appear perfectly healthy on operational dashboards, while inside it, an agent is consuming thousands of tokens in an erroneous decision cycle.

AgentOps was born specifically to resolve this void in visibility and control. It is not just a simple set of new software tools, but the necessary evolution to bring autonomous artificial intelligence to an enterprise-ready level.

Embracing this discipline means extending the engineering rigor typical of Cloud Native environments to the management of the generative model lifecycle, ensuring that their autonomy translates into a real competitive advantage rather than an uncontrollable operational risk.

What defines AgentOps compared to traditional operational disciplines?

AgentOps is the engineering discipline dedicated to the management, monitoring, and governance of the lifecycle of autonomous AI agents in production. Unlike traditional IT operations, it focuses on the observability and governance of stochastic decision-making processes, ensuring that multi-agent systems operate in a safe and predictable manner.

Defining the exact perimeter of this subject requires drawing boundaries with respect to pre-existing methodologies, even though there are obviously deep ties. As highlighted in recent academic studies, the epochal shift consists of transitioning from managing machines that execute deterministic instructions to supervising stochastic decision-making entities. A change not only technical, but also mental and approach-based.

AgentOps should not be confused with AIOps, which uses machine learning algorithms to optimize classic IT operations by predicting failures or analyzing logs. Similarly, it is clearly distinct from LLMOps, which is limited to the training, fine-tuning, and deployment of base models. The focus of AgentOps is the behavior of the agent as a whole: the use of tools, memory management, action planning, and interaction with the surrounding environment.

This transition entails a profound evolution of the DevOps engineer’s role. Infrastructure professionals must now acquire skills to manage semantic unpredictability. It is no longer enough to guarantee cluster uptime; it becomes essential to configure systems capable of intercepting behavioral drifts before they translate into destructive actions.

If the initial goal was to understand what DevOps is to automate code releases, today the challenge is governing artificial intelligence. To explore the origins of this methodological change, we invite you to learn more about the DevOps approach and its evolution in application development.

The stochastic nature of AI agents

The heart of the operational problem lies in the probabilistic nature of generative models. The challenges of this new paradigm are typically divided between intra-agent anomalies and inter-agent anomalies within multi-agent systems. At the intra-agent level, failures take subtle forms: an agent may lose operational context during a prolonged conversation, or suffer from a memory hallucination within a Retrieval-Augmented Generation (RAG) architecture, retrieving irrelevant documents and basing subsequent actions on them.

In multi-agent systems, complexity scales rapidly. Inter-agent anomalies include phenomena such as message storms, where two or more agents enter an infinite loop of requests and responses without ever reaching a conclusion, silently consuming computational budget.

In these scenarios, traditional logs are blind. An infinite reasoning loop does not generate CPU spikes or network latencies significant enough to trigger standard alarms. The infrastructure system works perfectly; it is the autonomous application logic that is flawed. For this reason, operational engineering must shift from monitoring physical resources to semantic monitoring of payloads and chains of thought.

What are the differences between AgentOps, DevOps, MLOps, LLMOps, and AIOps?

To navigate the complex ecosystem of modern operational methodologies, it is useful to compare the different disciplines. Each of them addresses a specific level of the technology stack, contributing incrementally to business stability and innovation. AgentOps is positioned at the top of this pyramid, orchestrating proactive decision-making automation.

Below is a structured analysis of the main operational disciplines and their impact on business:

What is the operational framework for the AgentOps lifecycle and observability?

The AgentOps operational framework structures the agent lifecycle through development, validation, deployment, and maintenance. It introduces reasoning observability to track decisions and implements remediation cycles to manage semantic anomalies, ensuring rapid and targeted interventions on unforeseen behaviors in production.

Structuring an agent’s lifecycle requires a rigorous methodological approach. During the development phase, prompt definition and tool assignment must be treated as source code, subject to versioning and peer review.

Validation represents a turning point: traditional unit tests are not enough, making it necessary to adopt patterns like LLM-as-a-judge, where specialized models evaluate the quality, relevance, and security of the responses provided by the agent in staging environments.

Even in the absence of a specialized LLM, it is advisable to use dedicated skills and different models for the evaluation and generation phases. A fresh and impartial pair of eyes, as in human peer review, is essential. The judge model must typically be different and preferably equipped with superior reasoning capabilities compared to the agent model to avoid self-evaluation bias.

Only after passing these dynamic benchmarks can the agent move to the deployment and subsequent adaptive maintenance phase.

The second pillar of the framework is reasoning observability. Tracking an agent’s final output is insufficient for debugging a complex error. It is essential to record the entire chain of thought, context logs, guardrail activation, and specific calls to external tools.

This level of transparency is fundamental to triggering an effective anomaly management cycle, allowing for accurate root cause analysis (RCA) and the application of targeted resolutions, such as prompt optimization or state rollback. To understand how these principles derive from managing complex systems, download the free guide on SRE to ensure application reliability.

AI Agent reasoning observability and telemetry

Extending Cloud Native observability stacks to support autonomous artificial intelligence is one of the most fascinating technical challenges of AgentOps. Established tools like Prometheus, Grafana, and Jaeger, originally conceived for microservice tracing, are now being configured to support distributed tracing of decisions made by generative models. Each step of the agent’s reasoning is treated as a span within a distributed trace.

This approach allows engineers to visualize exactly which fragment of context triggered a specific API call or why the agent decided to ignore a specific instruction. However, reasoning observability introduces unprecedented challenges related to data volume. High-frequency logging of input and output payloads generates an enormous load on telemetry systems.

Parallel to this, the crucial need to monitor costs emerges. Since language model provider APIs bill based on token consumption, an agent stuck in a decision loop can quickly exhaust the allocated budget. Grafana dashboards must therefore be extended to correlate technical performance metrics with financial metrics in real-time, implementing automatic circuit breakers that stop execution when spending thresholds are exceeded anomalously.

Similarly, in the case of using local models to ensure maximum data security, observability and cost monitoring are fundamental and present dedicated challenges, requiring, for example, careful measurement of GPU usage and inference times.

Anomaly management and remediation

Incident response flows specific to artificial intelligence differ radically from traditional ones. When an AI agent exhibits anomalous behavior, the primary goal is to contain the scope of action to prevent damage to infrastructure or corporate data. A concrete risk is tool poisoning, of which a well-known attack vector is Indirect Prompt Injection. The agent receives manipulated data retrieved from an external source that induces it to corrupt the application or execute destructive API calls, such as deleting databases or modifying network permissions.

To manage these emergencies, the AgentOps framework must provide immediate interruption mechanisms. Orchestration systems must be able to instantly revoke temporary credentials assigned to the agent or isolate it at the network level, blocking any outgoing communication. Remediation is not limited to containment but requires deep analysis to prevent the incident from recurring.

The integration of versioning and secure rollback concepts becomes essential. Every update to an agent’s behavior must be treated as a formal software release, whether it is a change to the system prompt, or the addition of a new tool or a new skill (i.e., a set of specific capabilities or functions, such as tool-calling, that the agent can invoke to solve sub-tasks).

If a new behavior proves unstable in production, operational teams must be able to perform a rollback to the previous state in a deterministic way, immediately restoring service reliability while conducting post-mortem analysis in isolated environments.

AgentOps in platform engineering: how does the Internal Developer Platform evolve?

In the context of Platform Engineering, AgentOps transforms Internal Developer Platforms, i.e., centralized portals for developer self-service, into intelligent ecosystems. Autonomous agents raise DevEx and reduce cognitive load, orchestrating complex resources, enabling self-service, and operating within perimeters well-defined by corporate policies.

Market data confirms that we are in a phase of profound architectural transformation. The ESG and Google Cloud report highlights how 55% of companies globally have already adopted platform engineering practices, and over 90% expect to expand their use in the coming years.

This massive adoption creates the perfect infrastructural ground for AgentOps. Centralized platforms provide the APIs, orchestration tools, and identity management systems necessary for AI agents to operate at scale.

Developer Experience (DevExp) is a fundamental parameter in Platform Engineering to measure a team’s engineering effectiveness. AI agents integrated into an IDP revolutionize this experience.

The ongoing transition sees Internal Developer Platforms evolving from static self-service portals, where the developer must fill out complex forms, into truly intelligent and proactive ecosystems. However, this efficiency cannot exist without ironclad governance: automation must be bound by policy as code to prevent misconfigurations.

To learn more about the impact of these dynamics on team efficiency, we recommend reading how to improve Developer Experience to reduce team cognitive load and our dedicated guide.

From static portals to intelligent ecosystems

The evolution of internal platforms is driven by the need to reduce the cognitive load on development teams. In a modern microservices architecture, requesting the provisioning of a new environment involves configuring repositories, CI/CD pipelines, Kubernetes clusters, databases, and network policies. Requiring developers to master every single tool drastically slows down software delivery.

AI agents solve this bottleneck by orchestrating resources autonomously. A developer can interact with the platform in natural language, requesting, for example, a staging environment optimized for load testing on a specific service. The agent analyzes the request, deduces the necessary dependencies, generates infrastructure manifests, and initiates dynamic resource provisioning, notifying the user once the operation is complete.

The reduction in cognitive load is immediate and quantifiable, and the business value generated by this transition is twofold. On one hand, accelerated onboarding is achieved: new hires can become productive in days rather than weeks, guided by the agent through the complexities of the corporate infrastructure. On the other hand, senior developers’ time is optimized, freeing them from repetitive operational tasks to focus on writing business logic and architectural innovation.

AgentOps and DevSecOps: security as a prerequisite in the era of autonomous agents

The autonomy of AI agents generates value only if they operate within a defined and automated security perimeter. With AgentOps, DevSecOps ceases to be a best practice and becomes an infrastructural prerequisite: every autonomous action, from resource provisioning to configuration modification, must be validated before reaching production. The Shift-Left approach, which integrates security from the earliest stages of the software lifecycle, becomes the architectural principle upon which to build trust in autonomous systems.

How to validate agent actions in DevSecOps pipelines?

Practical implementation requires AI agents to operate within a rigorous and immutable DevSecOps pipeline. Every proposed change generated by an AI agent must be treated as a standard pull request, subject to the entire chain of automated checks. There are no exceptions: whether the action was produced by an engineer or an agent, the validation process is identical.

This means integrating the right operational tools directly into the agent’s workflow. Every infrastructure change generated by AI, before being applied, must pass through static security tests (SAST), which analyze the proposed code for known vulnerabilities, and dynamic tests (DAST), which verify application behavior at runtime. This happens directly in CI/CD pipelines, thus validating the actions proposed by agents before deployment.

Container scanning systems complete the picture, confirming that the images used do not contain compromised dependencies. If an agent suggests updating a library to fix a performance bug, the scanning verifies that the new version does not introduce known vulnerabilities. Only after passing these checks can the change proceed.

Furthermore, in some advanced AgentOps frameworks, signals produced by these processes, such as pipeline rejections, approvals, false positives, scan results, and other specific instructions, become feedback that progressively refines the agent’s behavior. A system that learns and improves its security posture with use.

Policy as Code and security guardrails

The autonomy granted to agents within the platform requires the definition of rigid and impassable boundaries. The governance of this process is based on the adoption of Policy as Code. In the AgentOps field, security is implemented through two distinct types of controls: policy guardrails, which limit concrete infrastructure actions, and AI guardrails, which semantically filter the inputs and outputs of language models.

Policy guardrails are infrastructure constraints that limit the agent’s actions and circumscribe its effective scope. Using standards like Open Policy Agent, companies define rules that prevent artificial intelligence from performing non-compliant or destructive operations (such as exposing a database on public networks), regardless of the instructions received or the model’s deductions.

A concrete example clarifies the importance of these constraints: imagine an agent tasked with cloud cost optimization that identifies an apparently underutilized Web Application Firewall (WAF) and decides autonomously to turn it off to save resources. Without infrastructure policies, the action would be executed, exposing the company to critical risks. Policy guardrails intercept the API call, block it in milliseconds, and return a compliance error to the agent.

Another distinct but related concept is that of AI guardrails. These are systems that filter the agent’s semantic input and output, blocking the generation of harmful content or masking sensitive data before it is sent to language models. They are also used to block prompt injection attempts and responses not in line with the brand, avoiding equally serious reputational damage.

These filters also contribute to the security of corporate applications that integrate AI functionality, and require detailed monitoring and logging to verify their effectiveness.

A practical example is illustrated in our deep dive on AI Guardrails in Drupal: a SparkFabrik contribution to the open source ecosystem that demonstrates how to configure advanced security filters for incoming and outgoing data.

How is AgentOps applied in real operational contexts?

AgentOps applies transversally to infrastructure and software. Monitoring and governance rules govern both Virtual SREs for proactive Kubernetes cluster management and application agents that automate software delivery, customer care, and marketing operations.

Demonstrating the universality of the AgentOps framework is fundamental to understanding its strategic scope. The most common mistake is relegating this discipline exclusively to chatbot monitoring. On the contrary, observability practices, semantic failure management, and the imposition of guardrails apply with the same effectiveness to both base infrastructure and high-level application software. Engineering principles do not change as the agent’s domain of expertise varies.

To fully understand the foundations upon which these infrastructure agents operate, consult our complete guide to Kubernetes for container orchestration in complex environments.

Virtual SRE for infrastructure operations

A Virtual SRE is an autonomous agent designed to identify, diagnose, and resolve incidents in production without requiring continuous human intervention. Unlike traditional passive copilots, it operates as an active extension of the engineering team, marking one of the most advanced milestones of AgentOps applied to infrastructure.

Imagine an operational scenario on a Kubernetes cluster: a microservice begins to manifest a progressive memory leak over the weekend. Traditional alerting systems would send notifications to an on-call operator, requiring manual intervention to analyze logs, identify the problematic pod, and restart it.

A Virtual SRE (or SRE agent), equipped with the appropriate tools, intercepts the anomaly in real-time. The agent correlates memory consumption metrics with recent application logs, identifies the probable cause, and applies a temporary configuration patch, such as increasing memory limits or controlled pod restarts, notifying the team with a detailed report of the already resolved incident. This level of automation requires deep observability to ensure that the agent’s actions do not cause cascading service disruptions.

Similar scenarios apply to CI/CD pipeline optimization. Operating on complex cloud environments, an agent can analyze test execution times by interacting directly with Git repositories. If it detects that an end-to-end test suite systematically slows down releases without finding significant bugs, the agent can propose a reorganization of jobs or more efficient parallelism, opening an automated pull request to modify pipeline configurations.

It is crucial to emphasize that AgentOps does not replace operational teams, but empowers them. The Virtual SRE works alongside human teams 24/7, but strategic control remains firmly in the hands of engineers. Enabling this level of collaboration requires deep observability, continuous monitoring, dedicated training, and a strong propensity for experimentation.

Application agents for software delivery and workflows

Shifting the focus away from infrastructure, AgentOps demonstrates its value in managing agents specialized in application domains. In software delivery, coding agents do not just suggest code snippets, but generate entire features, perform pull request reviews, and write unit tests autonomously. The AgentOps framework ensures that the generated code meets corporate standards through automated static analysis.

A rapidly expanding area is agentic marketing. In this context, AgentOps governs complex systems that analyze the performance of hundreds of advertising creatives, recreate them while respecting the corporate tone of voice, and orchestrate batches of A/B tests in complete autonomy. Other specialized agents take care of generating and optimizing dynamic landing pages based on user behavior. Although the domain is creative, the need for governance is purely engineering-based.

Furthermore, other application scenarios exist in customer care, commercial processes, and logistics, where agents manage complex interactions with customers or optimize supply routes by processing massive amounts of data in real-time.

Managing these workflows requires the same operational guarantees as infrastructure. The need to implement session replay functionality to analyze past interactions, continuous quality assessment through judge models, and autonomy limitation to prevent reputational damage or budget waste remain identical. AgentOps provides the control structure necessary for artificial intelligence to operate safely in any business process.

How to structure an AgentOps adoption roadmap?

AgentOps adoption requires a pragmatic roadmap that starts with consolidating Cloud Native foundations. Through a human-in-the-loop approach, teams build trust in the system by validating decisions in read-only mode, before delegating low-risk operations to supervised autonomy in production.

Providing a clear guide to technology leaders is essential to avoid the typical failures of unstructured innovation projects. The path to AgentOps cannot ignore the consolidation of pre-existing automation practices. Implementing intelligent agents on manually managed or non-versioned infrastructure does not lead to efficiency, but amplifies technical debt.

To explore the strategic impact of this transformation, discover how intelligent agents transform processes and business.

The evolution toward autonomy typically unfolds through a logical progression:

1. Assessment and GitOps standardization: Companies must map their operational processes, identify bottlenecks, and ensure that infrastructure is declarative and deployments are fully automated. Attempting to apply AgentOps to manual processes means delegating the management of chaos to artificial intelligence. Furthermore, DevSecOps pipelines become the mandatory gates through which all agent actions pass. Without DevSecOps, giving an agent autonomy is dangerous.
2. AI-Assisted Observability (read-only): Agents are introduced without any modification permissions. Their task is to analyze huge volumes of logs, correlate events from distributed systems, and generate advanced incident reporting. This allows teams to calibrate telemetry systems and evaluate reasoning accuracy.
3. Remediation in non-prod environments: Agents obtain permissions to apply architectural changes and resolve incidents, but exclusively in development and staging environments. Within this controlled perimeter, self-correction capabilities are tested and policy guardrails are refined.
4. Human-in-the-loop automation in production: Agents monitor production clusters and propose detailed resolution plans, but actual execution requires the explicit approval of a senior engineer. This ensures absolute safety in high-stress real-world scenarios.
5. Supervised autonomy: After months of validation, specific, low-risk operational tasks, such as cloud cost optimization or predictive auto-scaling, are fully delegated to agents. The emphasis shifts to the robustness of orchestration systems, capable of isolating the agent at the first sign of an anomaly.

Managing AgentOps uncertainty as an emerging technology

Integrating AgentOps requires strong alignment of expectations at the executive level. CTOs must promote an organizational culture characterized by a marked propensity for experimentation and a healthy tolerance for initial failures. Language model “hallucinations” represent a concrete risk, and as these are emerging technologies, it is natural to explore various mitigation strategies.

To safely manage these uncertainties, it is imperative to design systems that provide for instant rollback actions and infrastructure immutability. If an AI agent applies an incorrect configuration, the orchestration system must be able to quickly restore the previous state. Resilience is an increasingly central value in modern architectures and becomes the prerequisite for safely experimenting with autonomous automation.

The “human-in-the-loop” approach proves essential not only as a security measure but as a tool for organizational learning. The transition from a purely AI-assisted approach (where the agent suggests and the human approves) to an AI-autonomous one must be gradual. This allows engineers to build trust in the models’ decision-making capabilities before loosening operational constraints, and to maintain human intervention for the most critical operations in production.

Conclusion

AgentOps does not represent a passing trend destined to fade with the artificial intelligence hype cycle. On the contrary, it establishes itself as a profound structural evolution, essential for managing the increasing complexity of modern distributed systems.

Delegating operations to stochastic decision-making entities requires a new approach, where reasoning observability and proactive anomaly management become the new success metrics for operational teams.

It is fundamental to reiterate that the success of autonomous artificial intelligence in production rests entirely on the solidity of infrastructural foundations. Without a mature Cloud Native architecture, devoid of rigorous DevSecOps practices and declarative resource management, AgentOps risks amplifying existing inefficiencies. Intelligent automation does not correct flawed processes; it simply executes them at a higher speed.

CTOs, Tech Leads, and infrastructure managers must objectively evaluate the maturity of their Internal Developer Platform and internal security skills before delegating critical operations to AI agents. Building intelligent ecosystems requires planning, specialized skills, and a security-by-design approach.

If you wish to explore how our experience can accelerate this transition in your company, discover how we integrate intelligent agents into business workflows and book a consultation to tell us about your project and your challenges.

Entrusting your corporate data to a closed system is like renting an apartment. You can use the space and certainly have some rights, but you don’t have control. The landlord can raise the rent, impose new rules, decide not to make improvements, or, in the worst-case scenario, evict you. In a corporate context, data sovereignty represents exactly this concept: the vital need to maintain absolute control over your information, deciding independently what to do with it, where it resides, and who can access it.

Data sovereignty is not just for industry insiders, and it is not merely a technical issue. It is a strategic choice that affects business survival. Today, the only real guarantee of independence for companies and for Europe as a whole lies in the adoption of open source software. Only when code is accessible, transparent, and not tied to a single vendor can an organization truly be considered the master of its own digital destiny.

According to the official definition by the Open Source Initiative, free software must guarantee access to the source code and the freedom of redistribution without discrimination. Without these pillars, your company risks getting trapped in rigid ecosystems, losing the ability to innovate and adequately protect your customers’ data.

This article is designed to guide business decision-makers, managers, and non-technical professionals on a path toward awareness. The goal is to provide practical tools to navigate between true open solutions and the false commercial promises that crowd the market. We will discover together why choosing open source is not just about saving on license costs, but represents life insurance for your company’s information assets.

What does it really mean to own your data?

Owning your data means having exclusive and permanent control over where information is stored, who can access it, and how it is processed, without depending on a single technology vendor. This operational independence ensures that the company can move its systems freely, protecting the business from sudden price hikes, license changes, or external interference.

Europe, the United States, and the race for sovereign cloud

The management of digital information has become a central theme in global geopolitical dynamics. Historically, the technology market has been dominated by United States vendors, whose internal regulations often conflict with strict European privacy laws. In fact, the U.S. government is actively opposing European data sovereignty initiatives, fearing the loss of strategic and commercial control over global information flows. This tension has pushed the European Union to seek greater independence, sparking a real race toward autonomous digital infrastructures.

Major technology players have quickly understood this market demand. Beyond the announcement of the AWS European Sovereign Cloud, we are seeing the birth of similar initiatives like Google S3NS and Project Bleu (a joint venture between Capgemini and Orange based on Microsoft Azure technology), demonstrating how proprietary cloud giants must adapt to the demand for physically and legally separate infrastructures for Europe.

However, there is an important distinction worth making, which allows us to view these announcements through the right lens. These offerings may reduce legal risks related to information residency, but they do not provide true technological sovereignty.

A cloud operated by a non-European hyperscaler remains, by its very architecture, controlled and strategically aligned outside of Europe.

In light of these limitations, what exactly is a company looking for when evaluating a truly sovereign cloud? There are three fundamental requirements:

• Data residency: information must remain physically within European borders, protected by local regulations and inaccessible to foreign governments.

• Access control: only the owning company and authorized European personnel must be able to view or manage the stored data.

• Operational independence: the infrastructure must be able to function in total autonomy, ensuring business continuity even in the event of disconnection from the main vendor’s global systems.

The role of regulations and the impact of the Cyber Resilience Act (CRA)

European regulations define precise rules for technological independence. The Cyber Resilience Act (CRA) is the new European law created to ensure the security of digital products connected to the network. This regulation establishes rigorous requirements for software and hardware manufacturers, obligating them to provide continuous security updates and to promptly declare any vulnerabilities.

The impact on companies will be tangible and cross-sectoral. For example, a company that produces connected medical devices will no longer be able to ignore security flaws in integrated software. Similarly, consider industrial IoT sensors used in factories, but also consumer devices (such as smart TVs, routers, and smartphones).

All these companies will have to integrate security from the initial design phases, the so-called security-by-design approach. They will also have to ensure that the software receives timely security updates throughout the product’s useful life.

The legislative landscape is increasingly and officially recognizing open code as a fundamental pillar for collective security. When source code is visible and verifiable by thousands of experts and developers around the world, defects are identified and corrected much faster than in closed and secret systems.

Transparent cybersecurity is the first, indispensable step to avoid being held hostage by third-party vendors. If you cannot inspect the software that manages your data, you must blindly trust the vendor’s promises. Conversely, the open approach allows for independent audits and verification that there are no hidden backdoors.

In this way, compliance with regulations like the CRA becomes a collaborative and transparent process, strengthening the true digital sovereignty of organizations.

To check the impact of this regulation on your business, we have prepared a practical guide to understand if your product falls under the CRA.

Why is open source the engine of European digital sovereignty?

Open source is the engine of digital sovereignty because it eliminates dependence on a single vendor, allowing companies to inspect, modify, and move their software freely. This technological transparency ensures total control over data, reducing migration costs and fostering secure, collaborative, and constraint-free innovation.

Beyond code: independence and reducing vendor lock-in

Have you ever wondered how much it would cost your company to migrate its entire management system if your current vendor decided to double their rates overnight? To understand the risk of relying on closed systems, imagine buying a high-quality camera, only to discover that its lenses work exclusively with that brand. If you wanted to change camera bodies one day, you would have to rebuy the entire set of lenses from scratch. In the software world, this expensive trap is called vendor lock-in.

Adopting open source solutions allows companies to change cloud providers or technology partners without having to rebuild the entire infrastructure. This freedom applies at all corporate levels. For example, developing solid open source intranet applications ensures that internal processes are not paralyzed if a vendor decides to change contractual terms.

Furthermore, using open source auditing software ensures absolute transparency in verification processes, an essential requirement for true independence. This freedom to innovate also extends to cutting-edge technologies. To understand how this philosophy is transforming complex sectors, we recommend reading our deep dive on AI for developers: the open source software revolution.

Open innovation is the only way to adopt new technologies while keeping the helm firmly in your own hands, giving managers true decision-making power.

The difference between proprietary SaaS and open solutions

The proprietary software as a service model has simplified access to many digital tools, but it has a hidden price: the loss of control. In a closed SaaS, your data resides on another company’s servers, which unilaterally dictates the rules for export and usage. Conversely, open alternatives allow you to host the software on your own servers or on a cloud of your choice.

Today, companies are looking for flexibility in every sector. In e-commerce, for example, evaluating open e-commerce platforms (such as those based on Drupal) compared to rigid SaaS ecosystems allows for customizing the shopping experience without artificial limits. This need for control covers every daily business requirement, from document drafting to accounting.

Think of historic office suites like Apache OpenOffice or LibreOffice, which have shown how it is possible to manage complex documents without paying recurring licenses. Even at a more strategic level, adopting open source ERP and CRM systems (like Odoo or Dolibarr) allows companies to manage accounting, inventory, and customers while maintaining absolute ownership of their corporate history. Let’s also consider Drupal, the leading open source CMS for enterprise and institutional contexts.

Choosing these tools means investing in a technological asset that grows with the company, rather than paying perpetual rent to third-party vendors.

Furthermore, it is important to highlight how the validity of open source alternatives is confirmed by the growing adoption of such solutions by governments and public institutions (for example, the French government’s transition from Microsoft 365, Teams, and Zoom to LaSuite).

Not all open source is the same: the scale of sovereignty

Not all open source software offers the same level of independence; there are different nuances. True sovereignty depends on the project’s governance and the degree of freedom afforded to the user. Solutions managed by neutral foundations guarantee total control, while projects led by a single company expose organizations to the risk of sudden license changes or usage restrictions.

The different levels of software openness

It is fundamental to understand that the concept of openness is not a simple on/off switch, but a spectrum with different nuances. To navigate this landscape, it is extremely useful to refer to the recent article in which Dries Buytaert, the creator of Drupal, formalized this concept by proposing the so-called “Software Sovereignty Scale”.

This scale helps decision-makers evaluate the real level of independence offered by a technology. The crucial difference lies in who holds the decision-making power: a project led by a single company, which holds the registered trademark, can change its license at any time for profit motives. Conversely, a project governed by a neutral foundation protects users from these commercial drifts, ensuring stability.

We can summarize the main levels of the scale as follows:

1. Total community control: The software is governed by a non-profit foundation. Decisions are made democratically, and no single actor can privatize the code. This is the maximum level of sovereignty.
2. Corporate control with open license: The code is accessible, but a single company decides the fate of the project and holds the trademarks. The risk of commercial shifts is always present.
3. Proprietary software: The code is closed, secret, and totally controlled by the vendor. The user’s sovereignty over their tools is non-existent.

Drupal as a prime example of an open ecosystem

When we talk about the maximum level of sovereignty, Drupal represents the perfect example. Often reduced to the simple label of a content management system, Drupal is actually an extremely powerful and flexible framework and ecosystem, used by the world’s largest organizations.

What makes Drupal unique is its distributed governance. There is no single corporate owner that can decide to shut down the project or make it paid overnight. Its evolution is guided by the Drupal Association, a non-profit foundation, and supported by a global workforce of thousands of developers and partner agencies.

This organizational structure guarantees organizations that adopt it true long-term independence. If the agency that developed your site closes or no longer meets your needs, you can easily find another vendor. The code is open and belongs to the community: no transfer is blocked.

This solid and secure architecture is ideal for building complex digital platforms, government portals, and critical business systems without ever ceding control of your data. Choosing a platform with this level of openness means investing in a technology that puts user interests above the profits of a single vendor.

At SparkFabrik, we don’t just use this technology; we actively participate in the forums where the future of the ecosystem is defined. In the most recent events, the dimensions of sovereignty and open source have emerged: themes that concern public administrations, as discussed at Drupal4GovEU, as well as the strategic evaluations of CTOs in private entities, as explored in our article on Drupal, AI, and platform engineering.

Thanks to this direct involvement in the ecosystem, and our vertical expertise in Cloud Native, AI, and supply chain security, we design and develop modern Drupal platforms optimized for performance, scalability, and security. With over a decade of experience, we are the reference technology partner in Italy. Discover our Drupal development and consulting services.

How to recognize (and defend against) the phenomenon of openwashing?

Openwashing is a deceptive marketing practice where proprietary companies promote their products as open source to attract customers, while maintaining exclusive control over the code. To defend themselves, companies must verify who holds the rights to the project and prioritize software governed by independent and neutral foundations.

What is openwashing and how to recognize it

The open software label sells well because it is synonymous with trust, security, and innovation. Unfortunately, this has generated the dangerous phenomenon of openwashing. It is a deceptive marketing practice where fundamentally proprietary companies use the open label to attract customers, while maintaining closed control over the core code, advanced features, or user data.

For non-technical managers, the risk of falling into this trap is very high. You believe you are buying independence, investing time and resources in adopting a platform, only to find yourself trapped in monopoly dynamics. Recently, we have witnessed numerous cases of large companies suddenly revoking open licenses for their products, switching to restrictive commercial models, and leaving customers with no viable alternatives other than paying increased fees.

How can you defend your company from these commercial traps? Here are two practical tips:

• Verify trademark ownership: try to understand if the software is managed by an independent foundation, such as the Apache Software Foundation, or if the rights belong to a single for-profit company.

• Check for locked features: if essential functions for security or enterprise integration are only available for a fee and their code is closed, you are facing a clear case of openwashing.

True commitment: SparkFabrik’s approach to the ecosystem

True digital sovereignty is not achieved simply by consuming free code downloaded from the internet. It is built by actively participating in communities, contributing to the continuous improvement of tools, and supporting the foundations that guarantee their neutrality both financially and operationally.

This is the principle that guides our daily choices. From our direct experience in developing complex enterprise portals, we have seen how adopting open standards drastically reduces time-to-market and ensures real scalability.

Our company’s concrete commitment translates into direct participation in the ecosystems that shape the future of technology. We are proud to belong to prominent international organizations such as LF Europe, the European division of the Linux Foundation, and the OpenSSF, the foundation dedicated to open software security.

But the commitment does not stop at memberships. We actively contribute to the code of the open source ecosystems we use, invest in spreading technical culture through articles and social content, and organize webinars and events like the Cloud Native Days Italy and the DrupalCamp Italy, which bring global communities on cloud native and Drupal to Italy. (Discover all our events!)

To learn more about our vision, we invite you to discover our manifesto and our commitment to the global community, an approach that is also reflected in our recent contributions to Drupal and AI in 2025.

This level of involvement is not just a badge to wear, but translates into a direct and tangible advantage for our clients. Working with a partner that sits at the tables where technological standards are defined ensures the adoption of high and constantly updated security protocols. Above all, it ensures that the proposed architectural solutions are truly free from hidden commercial constraints, putting the protection and sovereignty of corporate data first.

What are the next steps to ensure data sovereignty?

Data sovereignty is not just a technical problem, but a fundamental strategic decision that falls to management. Entrusting your information assets to open standards governed by neutral foundations is the only true antidote to vendor lock-in, ensuring freedom of innovation and long-term security.

At this point, one concept should be clear: entrusting your information assets to closed systems is equivalent to handing over control of the company’s future to third parties. The long-term economic and operational risks are concrete and difficult to reverse.

Adopting open standards, strictly governed by neutral foundations and supported by large global communities, represents the only true antidote to vendor lock-in today. This choice guarantees the freedom to innovate, compliance with strict European security regulations, and the certainty of being able to change technological course without suffering commercial blackmail. From the cloud to business applications, to content management systems, free and secure alternatives exist and are ready for enterprise-level challenges.

This path toward independence does not mean demonizing Big Tech. Without the enormous investments of players like Google, Microsoft, Amazon, or Red Hat, the current open source ecosystem simply would not exist.

The problem is not who built the tools, but who governs them.

Today, Europe contributes significantly to the development of open code, but invests very little in its ecosystem. The real challenge for our companies is to become leading actors in this technology, not just passive users.

Critically evaluating the state of your infrastructure is the first step toward building true independence. Is your data truly yours? Are you free to move it tomorrow morning without blocking business processes? To answer these questions and plan a secure transition toward true digital independence, it is essential to rely on expert technology partners like SparkFabrik.

Talk to our experts and discover how we can help you protect the value of your business by putting transparency, security, and freedom first.

Building your core business on a frontier API means delegating operational continuity to geopolitics. An infrastructure can shut down suddenly, not due to a technical failure, but because your country has been removed from a whitelist.

Access to frontier artificial intelligence models will not be universal: it is becoming scarce, selective, and shaped by geopolitics. The promise that LLM tokens would follow the trajectory of traditional software, becoming ever more abundant and ever cheaper, runs into the physical limits of today’s infrastructure and the strategic choices already being made by American providers. Anton Leicht crystallises this in his analysis Cut Off: frontier-model access is becoming a resource for the few. The first signs of the Californian taps being turned off demand a proactive change in course. Organizations can no longer simply consume external services; they must begin to engineer internal systems capable of operating autonomously, decoupling their business from future decisions made overseas.

The end of the Microsoft model and the Mythos case

Those who work in IT are accustomed to a precise logic: software has a marginal cost of zero. When Microsoft develops an operating system, the cost to distribute the first copy is immense, but the cost to distribute the millionth is irrelevant. This dynamic has convinced many decision-makers that frontier artificial intelligence will follow the same path as the mass market. Unfortunately, generative AI does not follow these economic rules.

The most direct evidence comes from Microsoft itself. The Redmond giant has announced that from June 2026 GitHub Copilot will abandon flat-rate subscriptions for usage-based billing based on AI Credits (github.blog). If the leader of the developer-tools market cannot sustain flat-rate pricing against inference costs, the illusion that AI tokens will follow the trajectory of traditional software pricing is officially over. The economic fracture between managed services and self-hosted infrastructure is the subject of our analysis AI agent harnesses: the great pricing divergence.

Frontier models are not infinitely scalable consumer goods. We got a taste of this at the beginning of April, when Anthropic announced Mythos, a top-tier model dedicated to cybersecurity. European companies expected to be able to integrate it into their workflows. Instead, scrolling through the announcement page, startups and system integrators from the Old Continent found a closed list of privileged partners, almost exclusively US-based corporations. Europe was left out, a fact also reported by Politico.

Observing the moves of competitors, a clear picture emerges. OpenAI recently launched the Daybreak initiative for its gpt-5.5-cyber model. In this case, too, the promise of a universal release was replaced by strictly limited access. Leading companies are giving the first signals that they want to close the gates.

Why is this happening? American companies are facing issues of physical, economic, and strategic survival. Value is shifting from the raw algorithm to the infrastructure required to run it securely, and that infrastructure is currently not enough for everyone.

The computational collapse and the threat of distillation

Providing access to a frontier model is a zero-sum game. Every generated token consumes real energy, real computing power, and physical hardware that cannot be allocated elsewhere. We are witnessing a compute crunch, a global supply deficit thoroughly analyzed by The Economist. The situation is so strained that even giants like Anthropic are forced to seek compute capacity deals with rivals like xAI.

Just as free cloud services impose strict storage limits (for example, the classic 15 GB maximum offered by Google Drive for basic accounts), AI infrastructures are hitting the insurmountable wall of the marginal cost per token. No software optimization can withstand the friction of physics.

Added to this limit is a devastating commercial problem: distillation. Fast followers, such as the Chinese company DeepSeek, manage to maintain a lag of only 6–9 months behind the American technological frontier. They do this by leveraging open API access to train their own models on the results generated by market leaders. The proliferation of open-source generative AI tools for development has enormously accelerated this knowledge transfer process.

The economics of this dynamic are unsustainable for those doing primary research. According to a study by the IAPS institute, frontier model developers today have a window of only 6 months to recover their immense investments in R&D before their model is cloned through distillation attacks. Opening an API to the entire world means selling your industrial secrets for a few cents per million tokens. The logical reaction we might see on a large scale is the closing of access, the implementation of rigorous Know Your Customer (KYC) checks, and the limitation of use to trusted partners. If the infrastructure creaks and intellectual property evaporates, politics intervenes to decide who has the right to sit at the table.

The geopolitics of tokens: when access becomes a weapon

The United States government has stopped viewing artificial intelligence as just another software sector. Today, it treats it as a critical national security asset and a powerful tool for diplomatic leverage. The dynamics at play closely resemble those of military cybersecurity.

The logic is ruthless but consistent. Anton Leicht raises an unequivocal point: if I were the NSA and I were sitting on a pile of zero-day vulnerabilities, I would absolutely want to know which of these exploits a model like Mythos is capable of finding. I would want to use that strategic advantage before vendors publish patches. This is not a conspiracy theory; it is the recent history of computing, as the EternalBlue case teaches us. Providing an advanced cybersecurity model to foreign governments or non-aligned companies means ceding a tactical advantage that is unacceptable to American intelligence.

This protectionist stance is reflected in concrete legislative initiatives. The GAIN Act proposal follows this exact trajectory, ensuring that American buyers have the right of first refusal on computational resources and tokens generated on national soil. Access to AI is becoming a bargaining chip in international relations, influencing trade deals and alliances, as highlighted by the tensions over technology agreements discussed by Donald Trump and Keir Starmer reported by The Guardian, or by the new regulations analyzed by the Washington Post.

The illusion of democratic access to AI risks vanishing soon. We are heading toward a global rift between those who control frontier models and those who are excluded.

Warhol used to say that the great thing about Coca-Cola is that the President of the United States drinks the exact same Coca-Cola that you do. Until yesterday, a small European agency queried the same OpenAI API used by the Pentagon, but the future trajectory points in another direction. This potential AI divide, analyzed by Foreign Affairs and RAND reports on global security, turns the impacts of the regulatory framework on the European Union’s digital sovereignty into issues of pure economic survival. The clock has already started: as the CEO of Mistral warned on Business Insider, Europe has a window of only two years to avoid irreversible technological dependence on the United States. For this reason, European companies and global middle powers (FAI) cannot stand by and watch, hoping for an invitation to the exclusive club.

Beyond the fence: hybrid architecture as the only way

If unlimited access to frontier APIs will no longer be guaranteed for everyone, how should a European company behave to continue releasing competitive software? The answer is not to build a trillion-parameter language model in the company basement. The solution lies in software engineering, specifically in AI layering and the adoption of hybrid architectures.

We must shift the focus from “which model to use” to “how to orchestrate models.” Building an application by binding it directly to the APIs of a single American provider is now an unacceptable architectural risk. Companies must build intermediate abstraction layers. Good architectural design allows for dynamic routing, evaluating the complexity of the request in real-time and routing it to the most suitable, available, and economical model at that moment.

In practice, imagine a customer support system. A simple ticket classification request is routed to a fast and cheap local model, while only the analysis of a complex legal contract reaches the expensive frontier model.

You don’t need an advanced generalist model to solve 80% of business problems. Local infrastructure becomes the true defensive shield.

Data extraction from an invoice or the generation of internal technical documentation can be brilliantly handled by local open-source models, trained and optimized for specific domains. This approach drastically reduces operational costs, ensures data privacy, and eliminates the risk of geopolitical lock-out. As highlighted by Leicht in his reflections on import imperatives and reiterated by RAND reports on data center security, maintaining control over your own computing environments is the only sustainable strategy.

The integration of artificial intelligence into enterprise architectures oriented toward sovereignty demonstrates that it is possible to maintain total control over one’s operations. Reserving calls to frontier models only for complex reasoning tasks means optimizing resources and protecting the business, proving that independence is first and foremost an architectural choice. In a period that Anton Leicht defines as the most dangerous time for AI policy, those who design compartmentalized systems survive future external blocks.

Conclusion

The exhaustion of universal access to frontier AI does not stop technological development, but it redefines its rules: competitive advantage shifts from the passive use of models to their control.

The scarcity of tokens and geopolitical restrictions are drawing a clear line between those who are subject to the decisions of large providers and those who maintain control of their own infrastructure.

The companies that will thrive in the next decade will not be those with the highest budget to pay for expensive overseas API subscriptions. They will be those that have understood how to protect digital transformation processes from service interruptions. Designing systems capable of functioning, scaling, and generating value even on the day the San Francisco tap might be turned off is no longer a theoretical exercise. It is the only sensible industrial plan to ensure the sovereignty and future of your business.

Imagine you have just purchased a powerful engine, the pinnacle of modern engineering. It is delivered to you on a wooden pallet, raw and bare. To use it on the road, you have to build the entire car from scratch. You will need to assemble the steering, brakes, fuel tank, and onboard electronics. Until recently, integrating an artificial intelligence model into an enterprise application worked exactly like this.

The model was the engine, but you had to build all the other necessary infrastructure to make it run yourself.

In our direct experience with cloud-native architectures, we have often seen emerging technologies redefine entire markets. Today, frontier model vendors are shifting the battlefield to orchestration infrastructure. The value has shifted from the intelligence of the model to the robustness of the harness that governs it.

A clear analysis by Janakiram MSV published on The New Stack highlights a crucial fact. The giants of artificial intelligence are offering this chassis with diametrically opposed business models. Anthropic rents it to you by the hour, as a turnkey service. OpenAI gives you the blueprints to build it, hoping you will use its engine exclusively.

This divergence is not a simple cloud pricing war. It is the exact moment that defines the new point of architectural lock-in for custom artificial intelligence software development. The choice between a managed service or an open-source SDK will not just impact the invoice. It will determine the portability, system flexibility, and technical debt that companies will have to manage for the next decade.

Let’s start with a practical example to understand how this infrastructure decision will radically change the way we develop software.

What is the harness and why has it become the real product

Defining a new standard

To understand the scale of this market clash, we must first demystify the object of the dispute. In short, a large language model (LLM), on its own, is limited to predicting the next word based on statistical calculation. It has no memory of past conversations, cannot query a corporate database, and cannot perform an action on external software.

The harness is the middleware that bridges this gap. It is the code that takes the user’s request, retrieves historical context, queries the necessary APIs, packages everything for the model, and then translates the textual response into a concrete action on the system.

The term began to circulate heavily in February. At that time, OpenAI published a technical post on its blog describing how a small internal team had managed to release a complex 1-million-line-of-code system into production. The unique part? Literally zero lines were written by human hands.

Martin Fowler definitively canonized the concept in a long essay, defining the exact boundaries of this architecture:

“The harness is everything surrounding an AI model, except for the model itself. It is the vital management infrastructure that turns an unpredictable text generator into a software operator capable of performing tasks in production.”

The harness manages model invocation and long-term memory. It handles the orchestration of external tools and code execution in isolated environments (sandboxes). It also regulates security permissions and error recovery. Without a robust harness, an AI agent is useless.

The hidden cost of DIY solutions

For 18 months, starting from the explosion of generative AI, the entire market lived in a technological limbo. Cloud vendors and framework creators offered only partial, fragmented, and often incompatible components. If a company wanted to bring an AI agent into production, it was forced to do the dirty work. Internal teams had to assemble custom solutions by gluing together open-source parts.

Startups raised capital to sell pre-packaged versions of this infrastructure. The harness became a market precisely because the available pieces did not provide a clean, definitive answer to enterprise needs.

In our work accompanying companies, we have observed the direct consequences of this fragmentation. Building a proprietary governance layer creates bottlenecks. Teams must personally manage the differences between orchestration and choreography in complex systems. They spend months just ensuring that every component communicates securely and deterministically, diverting resources from actual product development.

Now that the harness has a name and a defined perimeter, model creators have decided to reclaim this space. And they are doing so by imposing radically different worldviews.

The market crossroads: the “all-inclusive” approach vs. open source

The managed service path

The fragmentation of the last eighteen months is about to end, replaced by sharp polarization. On one side, we have the fully managed service approach. On the other, we find the path of open infrastructure based on the bring-your-own-compute principle.

Anthropic blazed the first trail by launching its Managed Agents service. The promise is a maximum reduction in cognitive load for development teams. You define the agent, the tools it can use, and the security limits. Anthropic takes care of running the execution environment. They manage long sessions, sandbox code execution, permissions, and end-to-end tracking.

The billing model is direct: $0.08 per session hour, in addition to token consumption. This is not a sandbox or simple prototype rate. Early enterprise use cases demonstrate that Anthropic’s approach is ready for heavy production:

• Notion uses these managed agents to perform dozens of delegation tasks in parallel.

• Rakuten has deployed agents specialized in sales, marketing, finance, and human resources.

• Sentry has built an agent that takes a reported bug and turns it into an open pull request, without any intermediate human intervention.

• Asana has integrated it into its AI Teammates feature.

We are witnessing the definitive shift from “do-it-yourself” orchestration to the Managed Agents model. The real news is the operational convenience: Anthropic takes charge of the execution infrastructure (the managed harness), leaving companies only with the burden of business logic.

The open alternative and ownership costs

Seven days after Anthropic’s launch, OpenAI responded with a mirror-image move. It released an update to its Agents SDK, strictly open source. This tool includes a native harness for OpenAI models, offering configurable memory, orchestration, and filesystem tools.

The crucial difference is in the delivery and pricing model.

OpenAI does not run the computation for you and does not apply any proprietary runtime costs or hourly fees. It provides you with the orchestration code, but you have to provide the physical infrastructure. The SDK natively supports 7 sandbox providers (Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel) and allows saving operation states on storage systems like S3, GCS, Azure Blob, and Cloudflare R2.

The total cost of ownership changes radically with this approach. If you choose an open-source agents SDK, you don’t pay framework licensing fees. However, you will incur processing costs for sandbox providers and cloud storage expenses to maintain agent memory. Furthermore, you will have to calculate the cost of the engineering time required to configure and maintain this distributed infrastructure.

This abundance of infrastructure options closely resembles the challenges of multi-cloud orchestration for organizations. The total cost for the company is not zero. But OpenAI deliberately chooses not to monetize the execution layer to drive pure consumption of its models.

The third way: Google and Microsoft’s granularity

Google and Microsoft are not standing by, but are proposing a third way based on service granularity. They have understood that enterprise companies might not want a closed package like Anthropic’s, but also don’t want to shoulder the total infrastructure burden required by OpenAI.

Google, with its Gemini Enterprise Agent Platform, has chosen to bill based on consumption for individual components, fragmenting the cost of orchestration based on what is actually used. Microsoft, with the Foundry Agent Service, applies pricing linked to the specific use of computationally intensive tools, such as the Code Interpreter. AWS follows this trend by preparing a Stateful Runtime Environment to manage long-term memory in collaboration with OpenAI and Bedrock AgentCore.

These giants confirm an unwritten rule of the new market: whoever controls the harness controls profit margins and the lock-in of the entire AI ecosystem.

The framework crisis and the internal team dilemma

Pressure on agnostic solutions

While artificial intelligence titans position their infrastructure pawns, the most violent impact is hitting the startup ecosystem. For months, horizontal frameworks thrived by filling exactly the void that major vendors had left open.

Take the case of orchestration frameworks designed to be agnostic to the underlying model. Tools like LangChain, CrewAI, and VoltAgent now find themselves in a position of extreme vulnerability. Curiously, VoltAgent is backed by heavy-hitting investors like Insight Partners, a fund that also invests in OpenAI and Anthropic.

Their main selling point has always been flexibility, promising to avoid ties to a single AI provider. But how do you sell an agnostic orchestration layer when the model creator gives you a native harness for free? Especially if this tool is open source, free, and perfectly optimized for its APIs.

The pressure is unsustainable. The promise of avoiding vendor lock-in loses its appeal when the third-party framework introduces latency or abstraction bugs. Often, these tools cannot keep up with the new features released by vendors, inevitably pushing development teams to prefer the native tool.

Survival niches

However, if the competition for basic orchestration seems lost, there are strategic exceptions for those who change the battlefield. Not all harness startups are destined to succumb.

Sycamore, for example, recently raised $65 million in a seed round led by Coatue and Lightspeed. The reason for this success does not lie in an attempt to compete on basic orchestration. They focused on a problem that major vendors do not want to solve, creating an operating system for enterprise AI focused on governance and multi-model control.

Large companies need unassailable audit trails. They require architectural strategies to mitigate the risks of non-deterministic systems and rigorous compliance guarantees. Sycamore survives because it sells independence and security at the enterprise level, not just developer convenience.

This market dynamic leads us directly to the heart of the problem for structured companies. Faced with the crisis of horizontal frameworks, the classic objection from IT departments re-emerges with force. Many think that if external frameworks are at risk and managed services create lock-in, it is better to build the harness in-house. In the context of generative artificial intelligence, this is a death trap.

The real cost is not on the invoice: the lesson of cloud computing

The end of the flat-rate illusion

The calculation between building an internal solution and buying one from the market has been enriched by two new benchmarks. On one hand, the convenience benchmark: Anthropic offers you complete infrastructure for $0.08 an hour. On the other, the supervision benchmark: OpenAI gives you the base architecture and lets you choose where to run it.

If you think execution and orchestration costs are a secondary problem that can be managed internally, look at what is happening to market leaders. Microsoft recently announced that from June 2026, GitHub Copilot will abandon the flat subscription model to move to usage-based billing based on AI Credits.

The reason is purely mathematical. Inference and autonomous session orchestration costs have become unsustainable with a flat fee. If a giant like Microsoft has to pass execution costs to the end user through a consumption-based system, thinking you can economically manage custom AI infrastructure within a normal company is a financial gamble.

For teams still in the prototyping phase, justifying building an orchestration infrastructure from scratch has become indefensible. Building memory, managing containers for code, and orchestrating tools was considered differentiating work. Today, it is a commodity accessible through a simple API call or by downloading a free SDK.

The hardest impact is for teams that already have systems in production. The typical objection is that the internal harness is perfectly optimized for the company’s specific workloads. The reality is much harsher:

An internal team of a few engineers cannot physically compete with the research budgets of four frontier vendors. Maintaining that custom system will become progressively slower and immensely more expensive.

Furthermore, it will become a nightmare for recruiting. What talented engineer will want to work on maintaining a legacy internal harness when the rest of the world uses market standards?

The historical parallel with cloud infrastructure

We have already seen this movie. The history of cloud infrastructure teaches us exactly how it will end.

When cloud computing became the standard, the market was not absorbed by a single monolithic solution. Terraform remained a dominant open-source standard even when AWS pushed its managed service, CloudFormation, heavily. Similarly, we saw the potential of open source in orchestrating scalable infrastructure establish itself with Kubernetes. It became the de facto standard, forcing AWS, Google, and Microsoft to offer managed services based on it.

The AI harness market will divide along the same geological fault line. Open source will not kill managed services, and managed services will not eliminate open source. They will coexist because they cater to fundamentally different buyer profiles.

Companies that prioritize time-to-market will gravitate toward solutions like Anthropic Managed Agents. Organizations that need granular administration will adopt architectures based on the OpenAI SDK or specialized frameworks.

The real lesson is clear. The harness, which until yesterday was supposed to be the defensive moat for many companies, has effectively become basic infrastructure.

Conclusion

Janakiram MSV’s analysis highlights an uncomfortable truth for the software industry. AI agent orchestration infrastructure is no longer the element that differentiates your product in the market. Tech giants have decided that the “chassis” must be standardized, using price leverage to impose their architectures, from hourly subscriptions to open-source gifts.

Building this infrastructure from scratch within your company means accumulating technical debt that will soon become unsustainable. The real decision today is not determining which language model is marginally more intelligent in a synthetic benchmark. The critical decision is choosing which orchestration architecture you want to tie your software’s operational destiny to.

We are witnessing a paradigm shift toward an agentic-first approach. The value no longer lies in building the infrastructure pipes, but in how artificial intelligence orchestrates real business processes. Choosing the wrong harness today means spending the next five years doing plumbing maintenance, while your competitors invent the future.

The Drupal Developer Days (DDD) 2026 in Athens showcased an open source ecosystem focused on structural engineering. Text generator demos have given way to concrete implementations. The community is actively deciding the rules of engagement for integrating large language models, favoring a solid architectural approach over passive adoption.

Artificial Intelligence was the cross-cutting protagonist of the event, viewed through the lens of technical pragmatism. Discussions covered AI as an advanced development tool, as a social phenomenon impacting team training, and as an opportunity to redefine the boundaries of the CMS. If you want to understand the starting point of this evolution, discover our complete overview of AI features in Drupal.

The message emerging from the Greek capital is clear: Open Source today represents a solid guarantor of digital sovereignty in a market driven by proprietary vendors. SparkFabrik participated by bringing real code and production-ready solutions to the stage, demonstrating that innovation is driven by solving complex problems.

Day 1 - The infrastructure of innovation and extreme performance

The integration of AI into Drupal is changing the very architecture of the system, requiring solid DevOps foundations. Technical sessions by Frederik Wouters, focused on Autonomous Drupal, voice commands, and conversational interfaces, and by Marcus Johansson, focused on the AI module 2.0, Guardrails, and the shift toward Symfony AI, charted the course. We are talking about an intelligence layer capable of orchestrating complex processes, analyzing context, and suggesting structural optimizations.

This ambition faces the physical limits of infrastructure. AI requires an underlying ecosystem capable of handling anomalous computational loads, where database performance remains the fundamental bottleneck.

Moving from 20 seconds to 500 milliseconds for loading a complex view is pure data engineering. Robin Colombier’s talk addressed the latency problem through the strategic use of materialized views on PostgreSQL. Instead of calculating complex queries in real-time with every request, data is pre-calculated and stored, updating only when necessary.

Artificial intelligence does not forgive fragile architectures. If the database is not optimized, adding AI agents in the background risks overloading the system under the weight of concurrent queries.

This optimization is a prerequisite for effective AI implementation. When an autonomous agent needs to analyze thousands of nodes to vectorize content, the database must respond in milliseconds. To support this horizontal scalability and manage load spikes generated by asynchronous operations, traditional on-premise infrastructure quickly shows its limits. In this context, explore the benefits of the Cloud Native approach for scalability, an architectural paradigm that allows for decoupling services and dynamically scaling computing resources exactly where they are needed.

Drupal AI 2.0: architecture and adoption status

Marcus Johansson outlined the status of the AI module and plans for version 2.0. Adoption is measurable: as of April 12, 2026, the AI module reached 13,980 active installations on Drupal.org.

The architecture is undergoing profound evolution, with the adoption of Symfony AI as a unified abstraction layer. On the security front, the Guardrails system is fully operational, preventing models from exposing personal data, generating out-of-context content, or responding to dangerous prompts (a contribution from SparkFabrik).

Two ready-to-use recipes are also already available: ai_recipe_guardrails_pii, which blocks emails, phone numbers, IBANs, and credit cards, and ai_recipe_guardrails_prompt_safety, which covers legal or medical advice, dangerous HTML, and code injection. Both can be installed with a single drush recipe command, offering a concrete and rapid implementation for those who want to start without building the configuration from scratch.

Furthermore, one of the ongoing developments is MCP (Model Context Protocol) support, which will transform Drupal into a tool queryable by external AI agents like Claude or Cursor. The maintainer of the Drupal MCP Client module is our own Roberto Peruzzo.

The first day therefore highlighted a practical principle: before implementing AI in the application layer, it is necessary to modernize the data layer and hosting infrastructure.

But the day did not focus only on code. There was also a broader perspective to consider.

Opening the day, in fact, was a fireside chat between Dries Buytaert and Prof. Dimosthenis Anagnostopoulos, Secretary General for Digital Transformation of the Greek government. It is not common to see a government representative on the stage of an open source developer conference. It is a signal: the topics the community has been discussing for years, such as digital sovereignty, control over infrastructure, and the risks of vendor lock-in on proprietary models, are entering the European political agenda. Open Source confirms itself as the guarantor of institutional control over data, a critical theme that invites you to delve into the importance of digital sovereignty in open source.

Day 2 - Automation, site building, and the evolving ecosystem

The second day shifted the focus from the database to the presentation and automation layer, highlighting the ongoing evolution in developer experience. Pierre Dureau’s session turned the spotlight on Display Builder. In particular, it focused on HTMX, a technology gaining traction in the community for its ability to modernize the frontend without introducing the complexity of heavy single-page application (SPA) frameworks like React or Vue.

HTMX allows for dynamic and partially updatable user interfaces by working directly with HTML rendered by the server. This approach reduces the cognitive load for development teams, keeping business logic anchored to the Drupal backend. In combination with emerging tools, interface creation becomes a fluid and modular process.

In this regard, the ecosystem is being enriched with advanced visual solutions; an excellent example of this evolution is documented in Michael Fanini’s talk on Display Builder during our own event Drupal X Business.

Parallel to the evolution of the frontend, the backend is experiencing an event-driven update. Jürgen Haas’s talk on ECA (Event Condition Action) showed how no-code and low-code automation is evolving natively within Drupal. ECA allows site builders to configure complex workflows, such as sending notifications based on specific triggers or manipulating entities, without writing a single line of custom PHP.

This accessibility of business logic is an important step. If AI is to interact with Drupal, it will increasingly do so by triggering events that the ECA system can intercept and manage.

At the recent DrupalCon Chicago, a figure regarding ECA emerged that makes all of this very concrete: Jürgen, as a senior developer and orchestrating advanced AI tools, wrote, validated, and documented 90,000 lines of code in just six weeks. This is not an experiment: it is a contrib module in production, used by thousands of sites. The data shows that AI as a skill amplifier is not an abstract concept, but is already measurable. We also discussed this in our article on the agentic-first approach to Drupal development.

Also very interesting was the talk by Klaus Purer, who presented Mago, a new PHP tool that can check coding standards and code issues in seconds.

The ecosystem is maturing to provide teams with tools that abstract technical complexity, allowing developers to focus on architecture and the integration of advanced services.

If you want to understand how these tools fit into the overall platform strategy, explore the evolution of Drupal CMS toward no-code.

Day 3 - Ethics, SDC, and SparkFabrik’s contribution

Technology without direction only produces technical debt. The third day of DDD opened by addressing the responsibility that comes with adopting AI, starting with Ifrik’s keynote on ethics. The community discussed the problem of bias in training datasets and the social impact of automation. These are not abstract discussions, but engineering decisions: how do we structure permissions so that an AI model does not expose sensitive data? How do we ensure that generated content is accessible and inclusive?

On the frontend development front, the push toward modularity found confirmation in the talks by David Galeano on advanced agentic workflows and FlowDrop, and Anand Toshniwal on Single Directory Components (SDC). SDCs support the developer experience: grouping markup, styles, and JavaScript logic into a single directory facilitates maintenance and the work of AI agents, which can analyze and generate isolated components with greater precision.

Symfony Messenger and Drupal Queues: SparkFabrik’s talk

Technological leadership is demonstrated by writing code and defining standards. SparkFabrik’s contribution to this architectural evolution came with Luca Lusso’s talk on Symfony Messenger and its integration into Drupal via the sm module (drupal.org/project/sm), an example of how we want to make a difference by tackling real problems.

Integrating artificial intelligence models requires external API calls that can take seconds to respond or fail due to network timeouts. Blocking the main PHP process while waiting for a response from OpenAI or Anthropic means compromising site performance. The sm module solves this problem, allowing heavy tasks to be delegated to asynchronous message queues managed by background workers.

This approach ensures resilient pipelines, with automatic retry logic in case of API failure, keeping the user interface responsive. It is a demonstration of how SparkFabrik tackles enterprise bottlenecks by releasing open source solutions for the entire community. To see how we bring these skills to the stage, watch our tech talks and interventions at international conferences. Solving complex asynchronous problems is the foundation upon which AI-based applications are built.

The human impact: training and AI as a skill amplifier

Interest in new architectures goes hand-in-hand with the challenge of talent sustainability. During the three days in Athens, the debate on mentoring in the AI era occupied a central space. If generative artificial intelligence is capable of instantly writing boilerplate, configuring routes, and drafting unit tests, how will new developers learn the fundamentals of the framework?

The risk is the atrophy of problem-solving skills. A junior who merely accepts AI suggestions without understanding their architectural implications will struggle to intervene when systems fail in production. The response that emerged from the community is that AI must not replace human mentoring, but transform into a support tool.

Continuous training therefore becomes a widespread priority, which does not only concern junior profiles. Even senior developers and tech leads must learn to govern AI, using it as a digital mentor to explore new languages or to perform complex refactoring, while maintaining control over domain logic. The goal is to develop critical thinking, shifting the focus from syntax to the design of secure and scalable systems.

Software engineering is not about typing code quickly, but about making correct architectural decisions. AI accelerates typing; the human must ensure the direction.

This is the approach we have formalized in our AI Vision: AI as a tool for augmentation, not replacement.

The best technology is born from the harmony between deep technical skills and solid human relationships.

In this scenario, on one hand, the need to implement a solid AgentOps approach for the orchestration of autonomous agents emerges, while on the other, the choice of Open Source technologies takes on strategic value. Maintaining control over one’s data, training models, and delivery infrastructure helps avoid the vendor lock-in imposed by large tech players, ensuring digital sovereignty, a critical issue especially for public administrations and large European enterprises.

Conclusion

The Drupal Developer Days in Athens showed how Artificial Intelligence in the Drupal world is integrating as an architectural requirement, pushing the community to adopt Cloud Native paradigms, asynchronous code, and optimized interfaces.

The future of Drupal is hybrid. On one hand, it requires technical efficiency to support autonomous agents and automations; on the other, it demands human responsibility to govern data ethics, accessibility, and team training. There is no sustainable innovation without rigorous control over software quality and supply chain security.

The community has demonstrated once again that Open Source is not just technology: it is the way collective trust is built around shared choices, as explored in our vision on agentic-first Drupal development. We were there, we contributed with real code, and we are already looking forward to the next appointment with the community at Drupal Developer Days Valencia 2027.

But before that, see you at DrupalCamp Italy 2026!

For decades, the software industry has operated according to a very permissive implicit logic: release the product quickly, and fix bugs and security flaws later through updates. A defect in the code could have serious effects, such as paralyzing hospitals or logistics chains, but most of the risk fell on the end users. The Cyber Resilience Act (CRA) puts an end to this logic.

In the world of physical products, however, manufacturers are subject to much stricter constraints and liabilities. For example, if a company places an appliance on the market with a manufacturing defect that risks causing a short circuit, the product is immediately recalled and the manufacturer is held legally liable. Until now, this level of direct responsibility did not exist for digital products.

With this new regulation, the European Union has decided to equate the digital world with the physical one. If you sell software in the European single market, you must guarantee its security from the design phase until the end of its lifecycle.

This is not a simple recommendation. Cybersecurity ceases to be an optional feature and becomes a binding requirement for market access.

Before tackling the complex technical challenges related to compliance, you must answer a fundamental question: does your product fall under this regulation?

In the following sections, we will explore exactly who is involved, who is excluded, and how risk classes work. We will guide you through the key concepts with the experience of those who have followed the evolution of this law since its first drafts, helping you turn a regulatory obligation into a real competitive advantage for your company.

Why has Europe decided that software can no longer ignore security?

Europe introduced the Cyber Resilience Act to make cybersecurity a mandatory legal requirement for digital products. The goal is to protect the market from systemic vulnerabilities, overcoming regulatory fragmentation and shifting the responsibility for security from end consumers to software producers.

Before the approval of this law, there were no mandatory minimum requirements. Each member state had different guidelines, creating a regulatory mosaic that penalized virtuous companies and left huge gaps in the protection of infrastructure. The burden of security fell on the shoulders of users, who were forced to navigate constant updates and complex configurations.

The decisive push for legislation came from the reality of the facts. In recent years, we have witnessed incidents that have shown how a single flaw can bring thousands of organizations to their knees simultaneously. These events made it clear that there is a need to understand the risks and vulnerabilities of the software supply chain to avoid devastating chain reactions.

Among the historical cases that guided the European legislator are:

• The SolarWinds attack, where malicious code inserted into a legitimate update compromised government agencies and Fortune 500 companies.

• The systemic vulnerability of Log4Shell, a defect in a tiny logging library that exposed millions of servers globally.

• The compromise of Codecov, which allowed attackers to exfiltrate credentials directly from CI/CD environments.

These incidents opened the eyes of legislators, highlighting systemic flaws capable of triggering devastating chain reactions. They demonstrated that the problem lies in the very foundation of development, affecting Supply Chain Security, or literally the security of the software supply chain.

The CRA reverses this logic: it moves from a reactive approach, based on the frantic release of patches after an attack, to preventive security. Security must be integrated from the design phase, adopting the principle of Security by Design, and companies will have to adopt rigorous software supply chain management practices.

It will be necessary to ensure that every third-party component is tracked, verified, and kept secure from the first day of development. For example, the use of tools to generate and monitor software bills of materials (SBOM) will become an operational standard for a secure software supply chain. It is no longer enough to react well; the law now requires designing securely.

Which software products fall under the scope of the Cyber Resilience Act?

The Cyber Resilience Act applies to all “products with digital elements” placed on the European market. The regulation involves manufacturers, importers, and distributors of applications, operating systems, firmware, and software components, establishing mandatory security rules for anyone who develops and markets technology in the European Union.

To understand if your company is involved, you must look at the definition of a digital product. The concept of “Products with Digital Elements” was deliberately formulated broadly to avoid legal loopholes. In simple terms, if your product contains code and communicates with the outside world, it is almost certainly subject to the regulation.

The law does not distinguish between a mobile application downloaded from a store, management software installed on-premise, or the firmware that runs a corporate router. If your code processes data or connects to a network, it is highly likely that it falls within the legislator’s scope.

The regulation precisely defines who must bear the burden of compliance:

• Commercial software producers, regardless of company size, who sell licenses or distribute apps in the EU market.

• Software component suppliers, including those who develop SDKs, libraries, or modules that will then be integrated into other companies’ products.

• Importers and distributors who place technologies developed outside the Union’s borders on the European market.

A crucial aspect to understand is the link to the secure software supply chain. The scope of the law is not limited to the code written by your developers, but includes all open source libraries and third-party components integrated into the final product.

In other words, you are legally responsible even for vulnerabilities present in external packages that you have decided to include. For this reason, it becomes vital to adopt principles and best practices for software application security from the very early stages of development.

Another highly debated point concerns SaaS (Software as a Service) platforms. Although the cloud infrastructure itself may fall under other directives, software provided via a SaaS model is often considered a product with digital elements.

If your company offers cloud services, it is essential to assess your position promptly and implement compliant software supply chain security strategies to avoid penalties.

However, the legislator has provided specific exclusions to avoid regulatory overlap:

• Software for internal use, custom-developed and used exclusively within the company without being commercialized.

• Products already covered by equally strict sectoral regulations, such as medical devices regulated by the Medical Devices Regulation or software systems for the automotive industry.

• Open source projects developed and maintained outside of any commercial logic, to protect research and free collaboration.

The goal is to create a secure supply chain at a continental level, targeting commercial products that pose real risks to users, without stifling internal innovation or over-regulating sectors that are already covered.

How do the Cyber Resilience Act risk classes work?

The Cyber Resilience Act classifies products into three levels: the Default Class for most software, and two classes of “Important Products” (Class I and Class II) for critical systems. Each level corresponds to progressively stricter conformity assessment requirements.

For a Project Manager or an IT manager, understanding which “drawer” to put their project in is the first operational step.

Europe has chosen a proportional approach. It makes no sense to impose the same security controls on a note-taking app and an enterprise-level firewall. For this reason, the legislator has structured a pyramid system that determines the effort required from companies.

For technical precision, it is useful to note that Class I and Class II make up the category of so-called “Important Products” (Annex III of the regulation). There is also an even narrower category of “Critical Products” (Annex IV) subject to specific rules. The following table summarizes how the main risk categories are divided.

The impact of the classification established by the CRA on modern IT architectures is profound. Fundamental technologies for the Cloud Native paradigm, such as container runtimes and hypervisors, have been explicitly included in Class II. This means that the engines that run the microservices of half of Europe will have to pass the strictest exams provided for by the law.

If your company develops or provides infrastructure based on Kubernetes or virtualized environments, the level of attention must be at its highest. It becomes essential to delve into the challenges and strategies of Cloud Native Security to understand how these requirements will change the way we orchestrate and deploy modern applications. The security of the underlying infrastructure is no longer just an operational best practice, but a certified legal obligation.

What are the deadlines and dates to mark for the Cyber Resilience Act?

The Cyber Resilience Act provides for a gradual application to allow companies to adapt. The key dates are June 11, 2026, for the operation of assessment bodies, September 11, 2026, for the obligation to notify vulnerabilities, and December 11, 2027, for full product compliance.

The regulation is now in force, and companies must start planning their adaptation to the CRA. The legislator has provided for a phased transition period to allow the market to organize itself without suffering sudden blocks.

Here are the legal deadlines that every Project Manager and CTO must know:

• June 11, 2026: Provisions relating to conformity assessment bodies become operational. The certification infrastructure for Class I and II products will officially begin.

• September 11, 2026: The notification obligation is triggered. Manufacturers will have to report actively exploited vulnerabilities and significant security incidents to the competent authorities within strict time limits.

• December 11, 2027: All mandatory requirements for new products come into force. From this date, no software subject to the regulation can be sold in the EU without demonstrating full compliance with the CRA.

From controversial proposal to law: what changes for open source?

The Cyber Resilience Act explicitly excludes open source software developed outside of commercial logic from its direct regulatory scope. This is a fundamental protection for the ecosystem that underlies Cloud Native technologies and protects independent contributors to the open source ecosystem.

Yet this exclusion is not a given: it is the direct result of a strong mobilization of the community, which obtained a revision of the original proposal and a much more balanced final text.

Today, the law makes a very clear and pragmatic distinction. If a programmer develops software or a library in their spare time and publishes it online as a non-profit open source project, they are not subject to the obligations of the CRA.

However, if a company takes that free project, integrates it into its proprietary software, and sells the final product, the company assumes full legal responsibility for the security of that component.

This mechanism shifts the responsibility exactly where the profit lies. Companies that use open source components to build their services will have to invest resources to verify the open source code they choose to adopt. A compromise that protects independent creators while forcing companies to do their part.

SparkFabrik and #FixTheCRA: when the community made itself heard

Achieving this regulatory balance did not happen by chance. It is the result of a strong global mobilization in which the technology community made its voice heard in a cohesive and structured way.

When the regulation was still in draft form, the original text presented a huge risk to innovation. The initial wording did not clearly distinguish between the release of open source code by volunteers and the placing of a commercial product on the market.

This would have made upstream contributors legally liable for the vulnerabilities of their projects, even when they were used by multinationals to generate profits.

Understanding the gravity of the situation, SparkFabrik and many other players in the sector joined the #FixTheCRA campaign promoted by the Linux Foundation Europe. Our goal was clear: to defend European competitiveness and the EU’s digital sovereignty without destroying the collaborative model on which modern software is based.

Our CTO, Paolo Mainardi, as an Advisory Member of the Linux Foundation Europe, actively participated in this advocacy effort. We documented and disseminated the community’s concerns for open source, explaining to policymakers that strangling independent maintainers would have made Europe less secure, not the other way around.

This effort reflects SparkFabrik’s deep commitment to the open source ecosystem, which we consider the true engine of digital innovation.

The community’s mobilization worked, leading to a final text that is much more balanced and aware of the actual development dynamics. In fact, today the position of Europe and public administrations towards open source software is increasingly favorable, recognizing its importance for digital sovereignty goals.

What does the CRA mean for your company and what are the next steps?

For your company, the CRA means having to accurately map all the software produced and used, assess risk classes, and prepare transparent documentation on dependencies. The first step is to perform a comprehensive assessment to identify current vulnerabilities.

The central message is unequivocal: the CRA transforms cybersecurity from an optional product feature into an indispensable legal requirement to access the European market. Today, it is no longer possible to think about releasing software without also thinking about security, starting from the design phase.

The first step is to understand if your product falls under the regulation and what risk level it falls into. This initial mapping is essential to avoid wasting resources or, conversely, underestimating strict legal obligations.

The next step is to understand how to address technical adaptation. This is a profound impact that requires specific knowledge, from secure dependency management to the implementation of automated controls in release pipelines.

Furthermore, it should not be forgotten that this law does not operate in isolation; it is part of a much broader European strategy. The European Union is building an integrated regulatory shield.

While the CRA focuses on the intrinsic security of products, it is also essential to analyze the impact of NIS2 and DORA on cybersecurity to understand how to protect critical infrastructure, always keeping an eye on the AI Act for high-risk systems.

To navigate this complexity and the transition to compliance without slowing down time-to-market, it is advisable to evaluate the support of an expert partner like SparkFabrik, capable of combining regulatory expertise and deep mastery of Cloud Native architectures.

As a guarantee of our competence in this area, SparkFabrik is in the process of ISO 27001 certification, the international standard for information security management. The synergy with the CRA is direct: the risk management and operational controls of ISO 27001 facilitate the risk assessments and secure lifecycle management required by the CRA. In fact, those who already implement ISO 27001 processes have a significant advantage in achieving compliance.

Despite the technical challenges, the Cyber Resilience Act should not be experienced only as a bureaucratic burden. This transition is an extraordinary opportunity to eliminate technical debt, improve product stability, and win the trust of enterprise customers, turning a legal obligation into a solid competitive advantage.

If your company develops commercial software or manages complex platforms, don’t wait until 2027 to discover that your architecture is not compliant. Find out how SparkFabrik can support you with the Cyber Resilience Act through assessment, modernization, and secure-by-design pipeline implementation services.

The web development market has undergone an irreversible fracture. On one hand, the proliferation of AI-based tools has reduced the creation of basic websites to a low-cost commodity. On the other, complex enterprise architectures require increasingly solid engineering foundations, and it is in this scenario that Drupal’s strategic repositioning fits. Choosing a core technology is no longer a tactical marketing decision, but a strategic imperative to support deep integrations and critical data flows.

The market for simple websites—those we define as showcase sites or brochureware—has been completely commoditized. Between closed visual site builders and the ability of GenAI to produce frontend code, the landscape has changed decisively. The value of building a simple site with a robust framework has collapsed.

As the low-end market saturates, a gap is opening at the high end. This is where the need to manage complex digital infrastructures, structured data, and business-critical processes arises. For years, the market treated content management systems as generic tools, but today that vision is obsolete.

This bifurcation is a hot topic that permeates the background of all strategic discussions. We have felt and experienced it at all the major conferences of the last few months.

It emerged as a central theme at Drupal Pivot EU, the exclusive unconference held in Ghent in January 2026. A restricted event that brought together leading European technology leaders to redefine the role of open source systems in enterprise architectures. We at SparkFabrik actively participated in the working groups with our CTO Paolo Mainardi, helping to chart the course for the coming years.

We saw the same common thread at Drupal4GovEU, the event focused on open source for the European Public Administration. And it obviously appeared in several talks presented at major events, such as the last DrupalCon in Vienna and the very recent DrupalCon Chicago.

The conclusion reached is unequivocal: continuing to treat content management platforms as simple web page providers is a calculation error that generates technical debt.

Indeed, Drupal is establishing and repositioning itself not as a simple CMS, but as the framework of choice for ambitious Digital Experience Platforms (DXP). We are no longer talking about managing web pages, but about governing APIs, digital identities, and complex workflows in a secure environment.

Forward-thinking companies are repositioning their investments. They are shifting budget from ephemeral frontends toward backend infrastructures that are governable, secure, and designed to last.

For a business decision-maker, understanding these dynamics is fundamental to correctly allocating IT budget. Continuing to treat Drupal exclusively as a content manager means underestimating a strategic asset essential for digital resilience, especially when combined with cloud-native technologies and AI.

Drupal as a business enabler: from CMS to Business Application Framework

Drupal has evolved from a simple open source CMS into a true application framework for the enterprise market. It functions as a business enabler by providing the architectural infrastructure necessary to manage complex workflows, advanced API integrations, and structured data, overcoming the functional limits of simple showcase sites.

During the working groups in Ghent, the discussion highlighted the need for an ontological redefinition. Market perception must align with the platform’s actual technical capabilities.

Traditionally, a CMS is viewed as a repository for text and images, but this vision is limiting. We no longer sell a packaged product. With Drupal, we provide a relational engine capable of orchestrating an entire company’s digital experience, thanks to an extremely flexible entity architecture.

This shift in perspective transforms the software from a cost center into a true Business Application Framework, capable of modeling unique business logic without forcing internal processes to adapt to pre-set software.

What does this mean in practical terms for the business? It means transforming the platform into the backbone for:

• Complex enterprise intranets: Granular permission management, multi-level approval workflows, and integration with corporate Identity Providers. (Discover the CNP Vita Intranet case study)
• Service portals: Where data security and accessibility are mandatory non-functional requirements.
• Headless Content Hub: Drupal acts as a single source of truth, decoupling the backend from the frontend and distributing content via REST or GraphQL APIs to various consumer applications.
• Data Management platforms: Native modeling of complex data relationships without the need to write SQL queries or manage manual schema migrations.
• LMS systems (Learning Management System): Proprietary e-learning platforms where progress tracking, skills certification, and protection of educational materials are non-negotiable requirements.

We see a concrete example in the manufacturing sector, where Drupal is adopted as middleware to aggregate data from ERP and CRM systems, exposing them in unified dashboards. This is a pure application framework use case, not that of a simple web page manager.

For IT decision-makers, understanding this evolution means entering a new era of content management for business, where content management is just a subset of much broader capabilities. There is now an unbridgeable gap between quick solutions and engineered platforms.

The difference between the two approaches manifests in several critical areas:

• Distinction between “disposable code” and “durable infrastructure.” AI, visual site builders, and modern frontend frameworks excel at rapid interface creation but introduce a high rate of obsolescence. Generated landing pages have a lifecycle measurable in months and do not survive corporate pivots.
• Long-term maintainability. The backend, business logic, and data model must ensure lasting stability. A Drupal-based infrastructure is designed for decade-long lifecycles, absorbing business evolutions.
• Isolated data vs. centralized hubs. Closed systems fragment information into inaccessible silos. A framework-first approach natively exposes every entity via REST or GraphQL APIs, acting as a single source of truth for omnichannel ecosystems.
• Standard logic vs. custom logic. SaaS products impose their own operational workflows. An open architecture allows for mapping granular permissions and approval flows exactly to existing corporate hierarchies.

Choosing this path means investing in a technology that scales with business complexity, ensuring solid foundations for the future. (To learn more: Complete Guide - Why choose Drupal for complex corporate sites)

Is Drupal the ideal solution for corporate digital sovereignty?

The advantages of Drupal for digital sovereignty lie in total control over architecture and data. Being open source, it eliminates the vendor lock-in typical of SaaS platforms, allowing CTOs to implement secure artificial intelligence models and maintain full infrastructure compliance without ceding control to third parties.

In the European enterprise market, the concept of sovereignty is often reduced to a mere matter of regulatory compliance and geographic server localization to respect GDPR. This vision is limiting. True technological sovereignty is only achieved when an organization possesses the unconditional ability to inspect, modify, and migrate its software stack without asking third parties for permission.

When critical infrastructure rests on closed cloud services, the company cedes control of its technological roadmap to the decisions of an external provider. Vendor lock-in represents the most underestimated operational risk in IT budgets today. Arbitrary changes to pricing models, sudden deprecation of fundamental APIs, or corporate acquisitions can paralyze a company’s digital operations.

Adopting open standards neutralizes this risk at the root. It returns bargaining power to management and the freedom to choose where and how to run their workloads, whether on hyperscaler cloud providers or private infrastructure.

This independence becomes crucial in the age of artificial intelligence. Companies possess invaluable information assets that cannot be fed into public language models. Sovereign AI requires platforms capable of orchestrating open source models or private instances within the corporate perimeter, allowing the use of artificial intelligence without exposing sensitive data to external networks.

The Drupal community shares this vision, embracing a vendor-agnostic approach that is easily adaptable. By using an open framework, it is possible to ensure security and compliance for corporate data by implementing Retrieval-Augmented Generation systems that query internal databases without ever exposing intellectual property on uncontrolled networks.

How does platform engineering transform Drupal into a durable infrastructure?

Platform engineering transforms Drupal into a durable infrastructure by applying cloud-native practices that ensure maximum reliability and scalability. By standardizing operations through an internal platform, development teams reduce cognitive load, cut technical debt, and significantly accelerate the time-to-market for new features.

The strategic transformation of Drupal into a business-critical application would not be possible without an evolution of the underlying infrastructure. Abandoning old monolithic hosting paradigms is the prerequisite for operating at an enterprise scale, in favor of a Cloud Native approach and Platform Engineering practices.

SparkFabrik’s vision is based on a rigorous engineering principle: the value of software is inseparable from the quality of the infrastructure that hosts it.

This is not a stylistic choice, but a reliability requirement. When an application becomes central to business processes, downtime or performance bottlenecks are intolerable. Investing in the underlying platform is the only proven method to mitigate obsolescence and ensure operational continuity.

To transform a CMS into a true cloud-native application, it is essential to create an internal developer platform to standardize operations. This methodological approach shifts the focus from manual server management to process automation, offering tangible business benefits:

1. Immutability and reliability through containerization. The use of containers and modern orchestrators (e.g., Docker, Kubernetes) allows infrastructure to be managed as code. Production environments are not “updated” manually, but replaced entirely with every deploy. This eliminates “configuration drift” and ensures that the development environment is identical to the production one, reducing unexpected bugs.
2. Horizontal scalability, resilience, and self-healing. Business applications have variable workloads. An architecture based on orchestrators like Kubernetes allows Drupal to scale horizontally (adding pods/nodes) in response to real traffic. This ensures high availability and self-healing, automatically restoring failed processes without human intervention and guaranteeing uptime.
3. Operational standardization and reduction of cognitive load with the Internal Developer Platform (IDP). By providing developers with standard paths and preconfigured resources, the need to manage complex infrastructure configurations is eliminated. Teams can thus focus exclusively on writing business logic. This accelerates time-to-market while maintaining centralized control over infrastructure governance.
4. Security integrated into the supply chain. By shifting security checks to the early stages of development, automated CI/CD pipelines block vulnerabilities before they reach production environments. This proactive approach is essential to meet enterprise security standards, from the very first line of code.

For IT decision-makers, the investment is not just in application software: the application and the platform must be designed in symbiosis. Without modern infrastructure, even the best Drupal code risks becoming unmanageable technical debt.

The impact of AI and agents in Drupal: collaboration or replacement?

Artificial intelligence does not replace software architecture, but enhances it by accelerating its tactical execution. Drupal provides the structure, validation rules, and data truth upon which generative models can operate, ensuring long-term governance essential for protecting corporate information assets.

The most common perspective error among IT decision-makers is considering AI as an alternative to traditional backend systems. On the contrary, advanced language models need structured platforms to avoid generating hallucinations or uncontrollable output. The integration between these two technologies pushes the framework up the corporate value chain, transforming it into the conductor of automated interactions.

The real leap in quality lies in Agentic AI, or the ability to orchestrate autonomous agents that operate within a governed perimeter. For development teams, this means moving from simple prompt writing to designing complex system instructions that allow agents to interact securely with platform APIs (agentic coding).

CTOs must adopt a new agentic-first approach to development, ensuring that the infrastructure provides the validation rules, semantic context, and operational limits within which artificial intelligence can move without corrupting corporate data.

AI enhances Drupal and, in turn, Drupal provides the perfect structured and orchestrated context in which AI can thrive. This “technological synergy” (widely debated at all strategic events, from the Drupal Pivot Unconference in Ghent to the major DrupalCons), manifests through practical applications that redefine team efficiency:

• AI content governance: Models generate massive volumes of information, content, and metadata, and Drupal acts as a control layer. It is the framework that orchestrates AI agents and imposes approval workflows, ensuring that every output respects brand guidelines and legal requirements before publication.
• RAG (Retrieval-Augmented Generation): In corporate contexts, AI must provide answers based on secure internal data. The platform acts as a central hub to orchestrate corporate data toward vector databases, allowing AI agents to answer user queries based exclusively on certified corporate documentation, accessing only pertinent information and strictly respecting individual access permissions.
• Development acceleration: Generating pages with GenAI, visual building, and automating repetitive tasks frees up valuable engineering resources. This allows technical teams to focus on architecture, complex integrations, and security.

To fully understand how to implement these hybrid architectures in your business processes, we recommend consulting our overview of Drupal AI and the SparkFabrik vision, where we analyze the most effective integration strategies.

In our deep dive on Guardrails in Drupal, we also take an in-depth look at a key system for enterprise applications, and in our article on Drupal AI 1.3, we explore the maturity of AI integration achieved with the latest version of the module.

The future sees technical teams focusing on data architecture and security. In our experience at SparkFabrik, adopting AI reduces development time for repetitive tasks by 30%, but only if the underlying framework imposes strict rules that prevent generated code from compromising system stability in production.

Why is the “Pivot” necessary now?

Drupal’s strategic repositioning is necessary today because the market has split sharply. While basic online presence is now commoditized, the demand for deep integrations is growing. CTOs need flexible platforms to solve the build vs. buy dilemma without ceding architectural control.

IT budget optimization requires ruthless choices, even more so today, in a market where code and online presence have become commodities. Financing custom development for low-impact projects is a waste of engineering resources, as automated tools can cover those needs at a fraction of the cost. Think, for example, of the myriad SaaS, “no-code” solutions, and AI builders for creating landing pages. In these cases, a technology like Drupal is clearly inefficient.

However, applying the same cost-saving logic to core systems generates technical debt that is paid for by the inability to scale. Enterprise companies no longer ask for digital showcases, but transactional ecosystems. Needs have shifted toward deep integration.

This level of complexity manifests in advanced use cases that escape the capabilities of traditional CMS s. Structured and complex business cases like customer portals, intranets, e-learning platforms, and data repositories require solid foundations.

In this scenario, technology leaders constantly face the Build vs. Buy dilemma. Buying a finished product guarantees initial speed, but SaaS black boxes show their limits as soon as business processes deviate from the vendor’s intended standard. Serious structural rigidities arise, such as non-modifiable data schemas, API limits, dependence on development roadmaps, and vendor lock-in.

Building everything from scratch, on the other hand, entails unsustainable maintenance costs. A mature application framework offers the optimal middle ground: solid foundations already written and tested, combined with absolute freedom to customize business logic.

The theme of digital sovereignty should be read from this engineering perspective even before a regulatory one. It is not just a matter of data residency, but of control over architecture. European companies need platforms where database access, business logic, and integrations are not bound by black boxes.

Drupal positions itself as an open source framework that guarantees full access to the stack, allowing data to be modeled exactly as required by the business. It offers the flexibility of custom code and the robustness of an enterprise framework, leaving the simple site market to automated tools.

What are the next steps for IT decision-makers?

Owning your technology in an era of uncertainty represents the ultimate competitive advantage for enterprise companies. The transition to robust solutions requires an in-depth audit of current infrastructure and the adoption of open source platforms governed by rigorous engineering practices, capable of supporting business growth in the long term.

Here is a strategic checklist:

1. Technical debt audit: Analyze your digital properties. Which are simple showcase sites and which are critical applications? Identify where you need control over data and software longevity. Those are the candidates for the new enterprise Drupal approach.
2. Technological independence assessment: Do your current systems allow you to extract and migrate data without friction? If the answer is no, you are accumulating operational risk. Adopting open standards and open source platforms is the most effective technical mitigation against vendor lock-in.
3. Platform-First roadmap: Stop funding siloed projects. Invest in the underlying platform. A cloud-native base has an initial setup cost, but it reduces the marginal cost of every subsequent application and ensures uniform security standards.
4. Partner selection: Modern challenges require skills that go beyond traditional CMS development. You need a partner with expertise in distributed architectures, application security, and DevOps practices. Look for proven expertise in SRE and software lifecycle management.

The dividing line in the IT market is now clearly drawn. On one side, we find companies that continue to squander budget on application silos and closed platforms, accumulating operational risks. On the other, industry leaders who invest in open, scalable ecosystems ready for the secure integration of artificial intelligence.

Drupal Pivot and other strategic events have confirmed that technological maturity is not measured by the quantity of features, but by the ability to govern complexity. Drupal has chosen to position itself as the tool for those who build durable digital assets, offering total control over their technology.

We invite technology leaders to evaluate their current infrastructure with a critical eye. Is it ready to support business-critical processes for the next ten years? Or is it time to “pivot” toward more robust solutions capable of supporting the business for the next decade?

If your architecture does not guarantee data sovereignty and operational agility, we invite you to discover our Drupal development and consulting services and contact our experts to design a future-proof cloud-native platform together.

Today, Drupal represents not only the best enterprise-grade CMS solution, but also the one that integrates artificial intelligence in the most mature way. The feature-rich 1.3.0 release of the Drupal AI module marks an important transition from an experimental integration to a production-ready platform. The adoption of LLMs in corporate CMSs has so far been held back by tangible risks related to data privacy, model hallucinations, and a lack of observability over background operations. This version tackles these structural criticalities, introducing advanced governance features, standardized telemetry flows, and orchestration tools that transform experiments into solid architectures.

The SparkFabrik team played an active role in the development of the core module, leading the design of the security and advanced search systems. The Cloud Native engineering approach made it possible to apply security-by-design and DevSecOps principles directly to artificial intelligence, ensuring that every interaction is traceable and secure.

To understand the extent of this ecosystem, it is useful to consult our complete overview of AI features in Drupal. As illustrated in the in-depth video by Marcus Johansson, Tech Lead of the Drupal AI Initiative, the update provides architectural foundations for complex operations. We detailed the journey of these implementations in our dedicated article on how we shaped the future of Drupal AI in 2025, demonstrating how the integration of language models requires cross-functional skills spanning CMS development and distributed infrastructures.

Why AI Guardrails transform Drupal into a secure enterprise platform

AI Guardrails transform Drupal into a secure platform by acting as bidirectional filters that intercept requests and validate the responses of Large Language Models. This governance system blocks the leak of sensitive data and prevents hallucinations, ensuring the necessary compliance for enterprise applications in production.

The implementation of these policies helps increase compliance on interactions with LLMs, both outbound and inbound. To delve deeper into the design of these components, you can analyze the architectural strategies to mitigate the risks of language models in the detailed article on Guardrails in Drupal AI.

During the Drupal X Business event, Luca Lusso presented in detail how these protection mechanisms work. In his talk, he highlighted how the implementation of strict rules shifts artificial intelligence from an experimental paradigm to a governable tool. The Cloud Native approach adopted in the design ensures that these controls operate efficiently, keeping latency very low to avoid negatively impacting editorial processes.

Interception and masking of sensitive data

Guardrails operate at a deep level of the architecture, preventing the leak of sensitive data before the HTTP request leaves the corporate servers. This includes blocking PII (Personally Identifiable Information), financial data, or intellectual property. The system can entirely block the request or mask the input using regular expressions or external validation services like AWS Bedrock.

A practical example illustrates the effectiveness of this approach. If an editor enters the code name of a classified product into a prompt, such as the internal project “MDX 250”, the configured Guardrail immediately intercepts the text. Or, much more simply, if a user sends their personal data or credit card number in the prompt, the system blocks or obscures them before sending them to public LLMs like those of OpenAI or Anthropic.

This preventive validation guarantees the security of the data supply chain, ensuring that the corporate infrastructure does not become a vehicle for the dispersion of trade secrets. The application of these filters happens in real time and provides immediate feedback to the user. By explaining exactly which security policy was violated, the system maintains a high level of awareness among editorial teams.

Agnostic architecture and bidirectional validation

The Guardrails system is designed with a strictly agnostic architecture, meaning it is not tied to a single vendor or a specific language model. This independence allows organizations to define centralized security policies. These rules remain valid even if you decide to migrate from one cloud provider to another, cutting down refactoring costs.

The protection offered by the module is structured on three distinct levels of intervention:

• Preventive blocking of the outbound request, which analyzes the user’s prompt and the provided context to identify violations of corporate policies before any network communication.
• Reformatting or blocking of the inbound response, which analyzes the output generated by the language model to intercept inappropriate content, offensive language, or responses that violate ethical guidelines.
• Prevention of hallucinations and maintenance of the corporate tone of voice, ensuring that the model does not invent non-existent facts or use a communication style foreign to the brand guidelines.

This bidirectional validation ensures that the CMS maintains final authority over the content. Artificial intelligence is treated as a service provider that must be constantly supervised by strict business logic.

How semantic Reranking improves RAG architectures on Drupal AI

Semantic Reranking improves RAG architectures on Drupal by introducing a second evaluation pass based on artificial intelligence. After the initial vector filtering, a specialized model reorders the retrieved documents by analyzing their actual contextual relevance, ensuring that Large Language Models receive precise information to generate responses.

The new Reranking operation type represents another area of strong contribution by SparkFabrik, essential for implementing effective Retrieval-Augmented Generation architectures. The adoption of these advanced techniques requires a new architectural approach oriented towards AI agents, where the precision of information retrieval directly determines the quality of the final output.

Development companies frequently clash with the limits of pure vector search, which often retrieves similar but not contextually relevant documents. By implementing reranking, we observed a 70% reduction in “false positives” during complex document queries and a more effective ordering of results. This deep semantic filter ensures that the language model receives only the strictly necessary context, also optimizing token consumption.

Overcoming the limits of standard vector search

A standard vector database returns results based exclusively on the mathematical distance between the coordinates of the texts in multidimensional space. Although this method is fast and useful for sifting through large volumes of data, it does not always understand the linguistic nuances or the real intent behind a complex query. The order of the documents provided as context to an LLM significantly affects the quality of the final response. In fact, models tend to give more weight to the information presented first, despite increasingly large context windows.

Re-ranking operates as a key second pass. After the vector search engine has retrieved an initial set of documents, for example, the first fifty results, a specialized model analyzes this subset. The model evaluates the actual semantic relevance of each document with respect to the specific question, assigning a new relevance score.

This process reorders the results, bringing to the top the documents that actually contain the answer, even if mathematically they were not the closest to the original query. The result is an optimized context that is then passed to the generative language model, drastically reducing the error rate.

Native integration between Vector Database and LLM

The technical flow implemented in version 1.3 involves a solid integration between an advanced search engine, such as Typesense (for which we are maintainers of the Drupal module) or a relational database with a vector extension, and the chosen AI provider. Drupal orchestrates this communication transparently. First, it queries the database to obtain the candidates, then it sends the results to the reranking service, and finally, it passes the reordered documents to the generative model.

This two-stage architecture increases the reliability of conversational systems. In internal document chatbots, employees get precise answers based on the correct corporate procedures. On e-commerce platforms, semantic searches return products that match the user’s purchase intent, significantly improving conversion rates.

By treating reranking as an agnostic operation, the infrastructure allows the use of specialized models (e.g., cross-encoders) trained specifically for the semantic reordering task. These models are architecturally different and much more precise in this phase compared to using a generative LLM. The most powerful and expensive generative LLMs can thus be reserved only for the final text generation. This separation of tasks optimizes operational costs and decreases the overall latency times of the system.

Cloud Native observability and advanced API management

Cloud Native observability in the Drupal AI module takes shape through the integration of the OpenTelemetry standard. This architecture allows tracking every single request to the language models, monitoring crucial metrics in real time such as latency, token consumption, and operational costs, treating artificial intelligence as a measurable microservice.

The implementation of artificial intelligence in production environments requires precise metrics and strict control over resources. This need explicitly connects to SparkFabrik’s engineering experience, where AI is not seen as a black box, but as a distributed component. To fully understand this architectural philosophy, it is useful to explore the fundamentals and advantages of the Cloud Native approach.

Version 1.3 of Drupal AI introduces native support for OpenTelemetry, allowing the tracking of the entire lifecycle of an autonomous agent. This level of transparency is necessary to diagnose bottlenecks and optimize performance. Having exact visibility into the costs per single AI transaction allows CTOs to justify technological investments to corporate stakeholders with irrefutable data.

Distributed tracing with OpenTelemetry

The standardized export of metrics, spans, and traces allows operations teams to analyze every single AI request with high granularity. When an editor requests the generation of a summary, the system records exactly how long the provider took to respond. It also tracks how many context tokens were sent and how many completion tokens were generated.

These data allow calculating operational costs in real time, associating the expense with specific site features or certain editorial flows. The open-standards-based approach guarantees compatibility with the most popular market tools, such as Honeycomb, Grafana, and Datadog. DevOps teams can visualize the performance of artificial intelligence on the same dashboards used to monitor the database or Kubernetes clusters.

The adoption of OpenTelemetry avoids lock-in to the proprietary monitoring tools of individual cloud vendors. Regardless of whether the infrastructure uses models hosted on AWS, Google Cloud, or local solutions, the format of the observability data remains consistent. This unified approach greatly simplifies the management of IT operations on a large scale.

Rate limiting, failover and normalized metadata

The advanced API management in version 1.3 transforms the way Drupal communicates with external providers. The system introduces rate limit thresholds and timeouts for HTTP requests that can be configured directly from the user interface. This new feature eliminates the need to write custom code to handle the limitations imposed by cloud services.

This evolution brings with it significant architectural advantages for platform stability:

• Implementation of automatic failover logic, which diverts traffic to a secondary model or an alternative provider when the primary service reaches the allowed request limit.
• Secure management of asynchronous calls, allowing AI agents to perform complex tasks in the background without blocking the main web server processes or causing timeouts for users.
• Normalization of metadata, which provides consistent information on model costs and technical capabilities regardless of the chosen provider, facilitating the switch from one vendor to another.

These protection mechanisms ensure that a spike in requests to the site’s intelligent features does not compromise the overall availability of the CMS. The platform degrades in a controlled manner, keeping critical services operational and ensuring enterprise-grade business continuity.

The automation ecosystem: from editorial workflows to AI moderation

The Drupal AI automation ecosystem optimizes editorial workflows by integrating decision-making capabilities directly into the content management interface. Through tools like Field Widget Actions and automated moderation, the system reduces the cognitive load on teams, transforming complex manual tasks into fluid and immediate processes.

These automation features make the offering of an AI software development company immediately tangible for the business. The impact translates into a return on investment based on time savings and the reduction of human errors (an estimated saving of over 20 hours per week of manual review and moderation for medium-sized editorial teams). The goal is to simplify content management by transparently integrating AI into daily operations.

User interface improvements include a new Markdown editor for drafting system prompts. This technical choice is particularly useful since language models interpret the Markdown format much more efficiently than HTML or plain text, and it is also possible to give a better structure to the prompts.

Last but not least, the Context Control Center allows you to define tone of voice, audience, policies, and specific corporate details just once, in a single environment and at one time. The various parts of the context can then be used by the different editorial teams to support their activities.

The CCC also supports the auto-completion of variables and tokens, thus allowing administrators to dynamically “inject” the data of the current user or node into the instructions sent to the model. This increases the overall precision of the context, consequently improving the quality of the LLM’s output as well.

And, tying back to observability, the CCC also has usage tracking, logging, and agent debugging features, as well as a wide range of automated tests that cover all its features—fundamental aspects for engineers.

Content moderation and Object Detection

Content moderation based on artificial intelligence introduces a level of automated control over the texts entered by users or editors. The system analyzes the content in real time and can autonomously alter the moderation state of the node. For example, if inappropriate language is detected, the state automatically changes from published to flagged, requiring the intervention of a human supervisor.

In parallel, the integration of Object Detection expands the analysis capabilities to multimedia content. Using computer vision models or deep learning algorithms, often run locally or through platforms like Hugging Face, the system recognizes specific objects within the uploaded images. This technology returns the exact coordinates of the identified elements, allowing for complex validations.

A typical use case involves blocking uploads that do not comply with corporate guidelines. The system can prevent the upload of an image if it does not detect the presence of a specific safety device in a construction site photo. Or it can reject images that contain competitors’ logos, automating a quality control process that would require hours of manual work.

Field Widget Actions for structured data

Field Widget Actions represent the deepest integration of automation within the editorial experience, bringing generative capabilities directly to individual Drupal fields. Instead of using a generic chatbot, the editor has contextual buttons that perform specific operations on the data during entry.

The technical use cases introduced (or improved) in version 1.3 cover a wide spectrum of operational needs:

• Extraction of physical addresses from unstructured text, normalizing geographical information through integrations with services like Google Places to automatically populate map fields.
• Generation of optimized SEO meta tags, creating catchy titles and relevant descriptions based on the analysis of the node’s textual content.
• Conversion of raw textual data into strictly structured JSON formats, an essential step for exposing consistent information via APIs in headless architectures.
• Automatic creation of FAQ sections starting from long documents and text-to-speech operations that transform textual articles into audio files associated with media fields.

These actions transform the CMS from a simple information container into an active assistant. By forcing language models to respect predefined data schemas, the system ensures that the generated output is immediately usable by the site’s display logic. This approach drastically reduces the need for manual cleaning and formatting interventions. Last but not least, these functions are easily usable by anyone, without particular technical skills.

Conclusion

Drupal AI 1.3 represents a major update that highlights the maturity of the ecosystem. By providing advanced tools like Guardrails for security, Reranking for semantic precision, and integration with OpenTelemetry for observability, the module offers the necessary infrastructure to operate in complex and regulated enterprise environments.

The secure integration of language models within corporate processes requires cross-functional skills that go well beyond the simple installation of a plugin. A deep understanding of CMS development, Cloud Native distributed architectures, and strict data governance practices is necessary. Only an integrated approach, guided by method and experience, guarantees that technological innovation does not compromise the security or performance of the system.

To orchestrate these technologies in a scalable and secure way, the added value lies in relying on technological partners with proven experience in open-source dynamics and in custom artificial intelligence software development. The evolution of Drupal demonstrates that the future of content management belongs to platforms capable of combining editorial flexibility with engineering rigor. Contact our experts and tell us about your challenges to discover how to implement these solutions in your architecture.

Artificial intelligence has transformed coding into a commodity: this is the inescapable truth for CTOs. And it is the central point of Dries Buytaert’s keynote at DrupalCon Chicago 2026, during the event celebrating 25 years of the Drupal open-source project. Source code is literally becoming a disposable resource. The true value of software development is rapidly shifting from mere coding to the rigorous definition of specifications and system architecture design. The result? A massive shift from manual programming to the orchestration of autonomous agents.

The observations that emerged perfectly reflect a core principle of the SparkFabrik Playbook. Ephemeral code frees up resources, but artificial intelligence does not replace software engineering; it exposes it ruthlessly. If a company has a clear vision and solid requirements, AI multiplies operational efficiency; in the absence of strategic direction, it merely amplifies errors on a large scale.

In this scenario, our Drupal development and consulting services are evolving radically, positioning us as strategic partners for the governance of digital processes and the implementation of enterprise-grade AI solutions.

Let’s explore in detail the main evolutions that emerged from the event:

• The architecture of DrupalCMS 2.1 and the new site templates that lower barriers to entry and accelerate time-to-market.
• The Context Control Centre, which allows you to configure tone, audience, and company policies just once for every AI interaction.
• The evolution of visual building with Canvas and the creation of production-ready pages via AI.
• The update of the Drupal AI module to version 1.3, featuring major innovations including the guardrails system contributed by SparkFabrik.
• The agentic-first approach and the redefined role of code in the AI era.

What are the new features introduced by DrupalCMS 2.1 for the enterprise ecosystem?

The main innovations introduced by DrupalCMS 2.1 for the enterprise ecosystem include an advanced architecture based on core 11.3, capable of reducing database queries by 50% for uncached pages. Additionally, the native marketplace is updated with 11 industry-specific site templates, specifically designed to drastically cut release times for complex corporate platforms.

The technological infrastructure presented in Chicago redefines performance expectations for large organizations. The DrupalCMS 2.1 engine does not merely update system dependencies; it rewrites the deep logic of data access. This structural optimization translates into immediate savings on cloud computational resources. Metrics show that corporate infrastructures can now handle intense traffic spikes with a fraction of the load on traditional servers, optimizing operational costs according to FinOps principles.

Alongside raw power, the engineering focus shifts to the speed of operational implementation. The new marketplace introduces 11 site templates specific to vertical sectors, from healthcare and education to financial services and public administration, available directly in the integrated marketplace.

This modular architecture radically transforms the classic conception of Drupal development. The months of work typically required for the initial setup of standard business logic and content modeling are eliminated.

For IT decision-makers, adopting this platform represents entry into a new era of content management for business. The technical advantages over legacy architectures and proprietary solutions are tangible and measurable:

• Drastic reduction in time-to-market thanks to pre-assembled configurations for specific industries.
• Optimization of the infrastructural load with a sharp drop in database queries and more aggressive caching.
• Native integration with GenAI services and solutions to streamline complex editorial workflows.
• Standardization of security best practices inherited directly from the evolution of core 11.3.
• The adoption of a fully open-source solution reduces the Total Cost of Ownership and eliminates vendor lock-in.

The impact of these innovations on IT budgets is direct and quantifiable. When engineering teams no longer have to spend tens or hundreds of hours configuring basic roles, permissions, and publishing workflows, the budget can be entirely redirected toward core system integration and advanced customization.

The role of the Context Control Centre in data governance

The Context Control Centre (CCC) is the new native subsystem designed to solve the problem of hallucinations in language models applied to the enterprise. Without this tool, every time AI is used, you start from scratch, forcing teams to re-explain the brand, correct the output, and redo the work. The CCC eliminates this inefficiency by allowing you to define tone of voice, audience, policies, and design just once.

Through the CCC, IT teams encode the corporate context via guidelines, brand voice, tone of voice, design systems, analytical data, and regulatory requirements (even in different languages). And they do it only once, directly in the CCC.

When artificial intelligence queries the CMS to create new content, the CCC ensures that the final output is perfectly aligned with corporate compliance standards. In this way, any deviation from the authorized communication perimeter is blocked at the source.

But the corporate context is not static. Products evolve, metrics fluctuate, information becomes obsolete. The CCC development team is exploring the concept of dynamic context: the ability to update the context as it evolves in time and to connect external data sources (like Google Analytics) directly to the orchestration engine.

The goal is an autonomously self-monitoring system. Imagine, for example, a sudden drop in key metrics, or pages with obsolete details that no longer reflect the current features of a product or service. With a dynamic context, the system would be able to detect these anomalies.

The direction is clear: moving from a context defined once to a context that evolves with the company itself. A CMS that doesn’t just produce brand-aligned content, but proactively flags when that content requires an update and proposes contextualized corrections. Of course, it is still in an embryonic phase, but it represents the natural frontier of AI orchestration applied to enterprise content management.

Canvas and Display Builder: how does visual creation change in Drupal development?

Visual creation in Drupal development is changing radically through the use of AI agents capable of transforming text documents into production-ready pages. Tools like Canvas (the flagship tool promoted by the AI Initiative) allow for rapid prototyping guided by artificial intelligence, while more mature solutions like Display Builder ensure the rigorous application of complex design systems on a large scale.

The latest practical demonstration of Canvas’s capabilities, in the plenary session in Chicago, shows a constant evolution of the tool, combining visual building and AI generation capabilities. A raw text document, containing only product specifications and unformatted copy, was converted into a complete web page in a matter of minutes.

This level of automation firmly positions the Drupal ecosystem at the top of AI-powered tools for accelerating the delivery of complex interfaces.

Unlike disposable prototypes created by external tools, Canvas operates natively within the CMS. Language models interpret the creator’s intent and map the content onto the visual components available in the system, keeping the permission structure, translation logic, cross-linking, and SEO metadata intact. The result is not a mockup to be rebuilt, but a production-ready page integrated into the corporate editorial workflow.

The new AI-assisted workflow transforms traditional frontend operations:

1. Loading text specifications or product briefs directly into the CMS interpretation engine.
2. Semantic analysis by AI to identify the logical structure, including headings, calls to action, and structured data.
3. Automatic generation of the visual layout by applying predefined components and Canvas typographic rules.
4. Human intervention for final accessibility validation, aesthetic refinement, and formal approval for publication.

For IT directors and product managers, understanding the integration of Canvas and native design systems becomes fundamental to evaluating the trade-off between execution speed and global visual standardization. While Canvas excels at rapidly generating new views, large enterprise architectures often require a higher level of architectural control over design tokens.

The solid alternative: Display Builder and design system integration

In contrast to the generative and prototyping-focused approach, the open-source ecosystem offers solutions specifically designed for visual governance on a global scale. During our Drupal X Business event, Michael Fanini presented Display Builder, a more mature visual builder developed to meet the most stringent needs of large omnichannel organizations.

Unlike tools focused on instantaneous speed, Display Builder offers deep and native support for complex corporate design systems (and is completely integrated with the ecosystem of modules and themes UI Suite). This feature ensures that every single component inserted into the page meticulously respects brand constraints, a non-negotiable requirement when providing development services and solutions for enterprises and institutions, such as multinational pharmaceutical companies or banking institutions.

To delve deeper into the potential of this enterprise visual architecture, we invite you to watch the full talk on our YouTube channel.

How does the Drupal AI 1.3 module guarantee corporate data security?

The Drupal AI 1.3 module guarantees corporate data security through a native Guardrails system that intercepts and filters communications with Large Language Models. This architecture applies pre- and post-processing validation rules, blocking the exposure of sensitive information and ensuring total regulatory compliance before publication.

The maturity reached by the open-source ecosystem transforms the Drupal CMS into a true enterprise-grade platform for the secure orchestration of language models. With the release of version 1.3 of the Drupal AI module, the community has established a new de facto standard for organizations seeking reliable architectures in the field of AI software development.

This release tackles head-on the main security issues plaguing CTOs in the AI space: the concrete risk of data leaks and the consequent loss of control over proprietary information, the hallucinations of probabilistic models, and the potential reputational damage of AI output not aligned with the brand.

The core of this infrastructural security is represented by the Guardrails system, a fundamental architectural component developed and contributed directly by the SparkFabrik team (discover all our contributions to Drupal AI).

As detailed in the article Guardrails AI in Drupal, we designed this protection layer to act as a bidirectional and real-time semantic firewall. Before a request is sent to external providers, the system proactively verifies the absence of personally identifiable information (PII), access credentials, or trade secrets.

Similarly, the post-processing phase analyzes the generated output to ensure compliance with current regulations, internal policies, and copyright restrictions. This architectural approach demonstrates how modern solutions must integrate robust safety nets, observable through standards like OpenTelemetry, around generative models.

Data security is no longer an optional add-on to be evaluated at the end of a project, but the indispensable foundation upon which to build any corporate automation initiative. Once the data security perimeter is locked down, companies can finally focus on the true value multiplier: the strategic orchestration of autonomous agents.

Why does the agentic-first approach redefine the role of AI software development companies?

The agentic-first approach redefines the role of development companies, transforming them from code executors to orchestrators of intelligent systems. Artificial intelligence does not replace engineers, but amplifies their architectural capabilities, allowing a single experienced professional to generate the qualitative and quantitative output of an entire team.

The practical implementation of this agentic-first model implies the integration of Artificial Intelligence as a native architectural component. The operational center of gravity is shifted from manual programming to the orchestration of AI models and agents and the configuration of automated workflows. And this requires precise technical knowledge gained from experience in real projects, Spec Driven Development practices, and rigorous data governance to ensure scalability and security.

Instead of writing individual functions, IT teams define the rules of engagement for multiple AI agents collaborating to solve complex tasks, from code refactoring to generating automated tests. This means being able to explore concrete application scenarios based on agentic AI that reduce bottlenecks in software releases, ensuring previously unimaginable operational scalability.

SparkFabrik’s vision embraces this structural transformation. Treating Artificial Intelligence as a simple external API enormously limits a platform’s potential. Conversely, designing systems where autonomous agents operate within a secure perimeter allows for the automation of entire business processes.

In our daily operational framework, we encode this transformation with an unequivocal principle: artificial intelligence does not replace you, it exposes you.

If you know what you want, it multiplies; if you don’t know, it amplifies errors.

The most glaring and documented demonstration of this augmented productivity came from the work of developer Jurgen Haas on the ECA (Event-Condition-Action) module. Assisted by advanced artificial intelligence tools, a single senior developer wrote, validated, and documented 90,000 lines of code in just six weeks.

This volume of work certifies that individual output is destined to scale dizzily, but only if you know what you want and if you start from a solid base of skills that allow you to orchestrate the work, holding the reins firmly.

To successfully implement the agentic-first approach, the architecture is based on three crucial phases:

• The design and implementation of centralized orchestration systems to robustly yet flexibly manage skills, system prompts, agent profiles, MCP protocols, and custom tools.
• The integration of guardrails and advanced security systems, rigorously applying DevSecOps practices to protect corporate data flows.
• The application of automated governance policies that validate the output of AI agents through automated testing prior to publication.

Software development companies that limit themselves to selling manual programming hours are destined for rapid obsolescence. The enterprise market exclusively rewards those who know how to govern systemic complexity and orchestrate ecosystems of intelligent agents.

Spec Driven Development and the harmony between skills and relationships

In an ecosystem driven by Artificial Intelligence, the quality of the generated output depends entirely on the precision of the initial specifications. SparkFabrik’s operational strategy is firmly based on Spec Driven Development. Language models operate exclusively within the boundaries outlined by system prompts and architectural rules. An ambiguous requirement, which in the past would have required clarification among developers, today translates into a large-scale hallucination or an application outage.

Consequently, the role of the CTO and VP of Engineering is increasingly focused on validating information architecture and data security. The value of technical management shifts from source code review to the definition of unassailable API contracts and the verification of access policies. The success of an enterprise Drupal development project is measured today by the robustness of its specifications, which act as the true source code for AI agents.

The market is clearly rewarding entities capable of bridging this gap, transforming agencies from simple labor providers into strategic consultants. Fundamental to the transition, however, is understanding that the commoditization of code is not something to be feared, but a profound change to be managed with clear strategy and governance.

AI automates execution, but strategy requires empathy and a deep understanding of the client’s business on the one hand, and training and change management internally on the other. As we openly declare in our company Playbook, technology changes at a dizzying pace, but our founding principles remain steadfast.

“What won’t change is why this company exists. Our vision has always been harmony between skills and human relations.”

The future of IT belongs to those who can balance the computational power of autonomous agents with the irreplaceable human ability to build lasting relationships of trust.

DrupalCon Chicago 2026: what are the impacts and takeaways?

What should we take away from DrupalCon Chicago 2026? The message for decision-makers is clear: the modernization of enterprise systems no longer involves the endless manual rewriting of code, but rather the agentic approach.

Contemporary Drupal development represents the true vanguard in the orchestration of autonomous agents within an intrinsically secure, scalable framework governed by clear rules. From the optimized performance of core 11.3 to the rigorous management of semantic context via the Context Control Centre, the open-source platform confirms itself as the platform of choice for large organizations that reject the vendor lock-in of proprietary models.

SparkFabrik does not limit itself to observing market trends or passively using these new generative tools. As demonstrated by the release of the Guardrails system and other contributions, we are actively committed to forging the technologies that define the new global standards for security, governance, and development. We position ourselves as the ideal strategic partner to guide companies through the treacherous complexities of application modernization and the secure adoption of artificial intelligence models.

Explore our custom AI solutions and speak with our experts for tailored architectural consulting, designed to solve the specific challenges of your organization.

Have you ever sat down at your computer one evening to book a medical appointment through your region’s portal, or to pay your municipality’s waste tax? You enter your personal details, provide sensitive information about your health or assets, and click “submit”. But have you ever wondered where that data physically ends up? Who owns the servers where it’s stored? And above all, who wrote the code that manages such delicate information?

These questions are no longer mere speculations for industry insiders, but represent the core of a fundamental debate for our future. On January 29, 2026, the city of Brussels hosted the first edition of Drupal4Gov EU. This event, organized during the Open Source Week by the European Commission’s Drupal Community of Practice and the EUIBAs, proved to be a crucial moment for defining the guidelines for tomorrow’s public services.

During the conference, an unequivocal truth emerged. Digital sovereignty is not an abstract concept or a bureaucratic whim, but a practical and urgent necessity. European governments and institutions are addressing this challenge through the strategic adoption of open technologies. In this scenario of profound transformation, open source platforms like Drupal are at the forefront, offering the necessary tools to build a secure, transparent, and truly independent public infrastructure.

What is digital sovereignty and why does it concern all of us?

Digital sovereignty is the ability of a State or institution to exercise full control over its technological infrastructure, citizens’ data, and the software used. Without this autonomy, government bodies depend on external providers, losing decision-making power over essential public services.

To understand this concept, we can use a metaphor very close to everyday life: the difference between renting and owning a home. An institution that does not control its technology is exactly like a tenant. It can use the apartment, but it doesn’t have the keys to change the lock, it can’t decide to renovate the rooms, and, even worse, the landlord might decide to drastically increase the rent or evict them with little notice. Building services for citizens on closed, proprietary platforms effectively means handing over the keys to the public house to private entities.

To ensure true independence, control must be articulated on three fundamental levels:

• Control over data: This concerns the physical location where information is saved. Citizens’ health, tax, and personal data must reside on servers subject to European regulations, protected from interference or surveillance by third-party nations.
• Control over operations: This defines who physically manages the systems day-to-day. Administrations must be guaranteed that critical infrastructures are not interrupted or altered by corporate decisions made on the other side of the world.
• Control over technology: This concerns who writes, inspects, and modifies the source code. Only by having access to the internal mechanisms of the software is it possible to verify the absence of hidden vulnerabilities and adapt the tools to the real needs of the community.

The impact of all this on citizens is direct and tangible. Privacy protection cannot exist without mathematical certainty of how data is processed. National security requires government systems to withstand technological blackmail or cyberattacks. Finally, the continuity of essential public services must be guaranteed at all times, ensuring that a hospital, a court, or a municipality can always operate without depending on the commercial fate of a single software provider.

How does open source ensure the digital sovereignty of Public Administration?

Open source ensures the digital sovereignty of Public Administration by eliminating vendor lock-in, which is the forced dependence on a single technological provider. By adopting open code, governments retain the freedom to inspect, modify, and transfer their systems without being subject to commercial constraints or external technical limitations.

The concept of vendor lock-in is one of the most serious risks for a public body. When an administration purchases closed software, whose internal mechanisms are secret, it becomes inextricably linked to the company that produces it. If that company decides to double license prices, discontinue technical support, or change product features, the entity has no alternatives. Migrating to a new system would cost too much time and money, forcing the government to accept unfavorable conditions paid with taxpayers’ money. Open code breaks this chain, restoring total freedom of choice and maneuver to institutions.

During the event in Brussels, an extremely effective analogy was used to explain this dynamic: the aqueduct analogy. A government has an absolute duty to ensure that the drinking water reaching citizens’ homes is safe, clean, and free of pathogens. To do this, it cannot merely trust the word of a private supplier; it must be able to inspect the pipes, analyze the sources, and check the filters.

The exact same principle applies to technology. A government must independently know and verify the software on which citizen services are based. If the code is secret, inspection is impossible. And it’s also a matter of responsibility: a government is also responsible for knowing which open source software projects are safe and reliable to use. And the only real way to do that is to be directly involved in how these projects are created and maintained.

This requires a profound cultural and financial paradigm shift on the part of institutions, similar to the accelerated digital transformation during the pandemic. It is no longer enough to purchase licenses as one buys stationery. As a company strongly committed to the development and promotion of the open source ecosystem, we are well aware of this dynamic.

As our CTO Paolo Mainardi precisely highlighted during the reflections arising from the conference:

“Open Source is a public good that must be supported and funded in a new, modern way: like public infrastructure”.

Free software must be treated, funded, and maintained exactly as highways, bridges, or, indeed, public aqueducts are.

Drupal4GovEU: Digital sovereignty lessons from the heart of Europe

The first edition of Drupal4GovEU demonstrated that to achieve true digital sovereignty, European institutions must stop being mere consumers of software and become active contributors. Participating in the open source ecosystem is the only way to ensure the security and continuous evolution of public services.

Our direct observations from the conference confirm an unequivocal trend. Administrations that merely download and use open code gain only a partial benefit. To truly govern technology, it is necessary to sit at the decision-making tables of communities, propose changes, and invest resources in shared development. For those who wish to delve deeper into the individual presentations, the official event playlist on YouTube is available, a valuable resource for understanding the direction of European public innovation.

The active role of governments and local artificial intelligence

The shift from passive users to active creators was the focus of Sachiko Muto’s keynote, titled “Unlocking Public Sector Contributions to Open Source”. Her speech clarified how governments must structure themselves to be effectively involved in open source projects.

Being directly involved, funding development, and allowing their internal developers to write code for open projects is the only way to fully understand how these high-public-interest projects (really) work. Only by contributing directly can institutions ensure that the software precisely meets the complex needs of the public administrative machine.

“Public institutions should take part in open-source projects not only by providing funding, but also by actively contributing to them.”

This need for control becomes even more pressing when it comes to new technologies. Josef Kruckenberg illustrated an illuminating practical case in his presentation “How AI is Supporting End Users and Editors at the Canton of Basel-Stadt”. The Canton of Basel has implemented an AI-based chatbot to help citizens handle bureaucratic procedures quickly and intuitively. The true innovation, however, lies in the system’s architecture.

To keep sensitive data secure and ensure digital sovereignty, the entire artificial intelligence model is hosted in Swiss data centers, such as those provided by Infomaniak. This approach demonstrates that it is possible to combine the most advanced technological innovation with rigorous protection of local data, without ceding information to overseas providers.

Accessibility and scalability for European citizens

Beyond security, public platforms must handle immense traffic volumes while maintaining structural consistency and accessibility. Sandro d’Orazio and Massimiliano Molinari recounted the European Commission’s successful journey in creating a centralized solution for the Europa.eu domain. Using a Drupal-based architecture, they managed to consolidate hundreds of fragmented websites into a coherent ecosystem, drastically improving security, scalability, and user experience for millions of European citizens.

But a scalable service is useless if it’s not usable by everyone. Mike Gifford’s talk addressed accessibility not as a mere technical requirement, but as a fundamental right. Gifford explained the practical impact of the Web Accessibility Directive (WAD) and the European Accessibility Act (EAA).

Building an accessible government website, which allows people with visual, motor, or cognitive disabilities to navigate without obstacles, is not just an obligation to avoid legal penalties. It is an essential civic duty. Open platforms allow communities to develop modules and themes already compliant with these directives, facilitating the work of administrations in ensuring total digital inclusion.

Why is Drupal the engine of innovation for complex institutions and highly regulated industries?

Drupal has established itself as the engine of innovation for complex institutions thanks to its flexible architecture, highest security standards, and the support of a vast global community. This open source platform allows managing enormous volumes of data while ensuring total adherence to regulations.

During the Brussels sessions, it became clear that this CMS (Content Management System) is no longer considered just one option among many, but the platform of choice for high-level government portals. A concrete example of this excellence is the official European Union portal, Europa.eu, which manages vital information for millions of citizens in dozens of different languages.

Drupal’s strength lies in its ability to model extremely complex information architectures, typical of ministries or large public agencies. Furthermore, the open nature of the code allows thousands of developers worldwide to identify and resolve potential vulnerabilities with a speed that proprietary software cannot match.

Security and regulatory compliance are non-negotiable pillars for the public sector. An architecture based on open technologies greatly facilitates adherence to stringent regulations. As we analyzed in our in-depth look at the impact of NIS2 and DORA on cybersecurity in Cloud Native, institutions must ensure proactive resilience against cyberattacks. Drupal integrates perfectly into modern cloud ecosystems, allowing the application of rigorous security policies and maintaining full control over who accesses critical information.

Our team’s direct experience confirms these potentials. At SparkFabrik, we design and develop solutions for organizations that cannot afford the slightest margin of error. We have carried out complex projects in areas where security and stability are vital, providing digital solutions for financial services. We are talking about critical platforms for clients of the caliber of London Stock Exchange and Borsa Italiana/Euronext that are based on robust architectures requiring levels of reliability comparable, if not superior, to those of governments.

Similarly, we manage large-scale modernizations in the education sector, as demonstrated by our work for La Scuola, where we implemented a secure and scalable infrastructure based on Drupal 10. These experiences demonstrate that open technologies are ready to support the most critical and challenging workloads.

Conclusion

The first edition of Drupal4GovEU has drawn a clear line for the future of European digital services. Digital sovereignty, uncompromising accessibility, and the strategic adoption of open source are no longer theoretical concepts, but the three pillars on which to build a modern, efficient, and truly citizen-centric Public Administration. We have seen how control over data and code is the only effective shield against vendor lock-in and how active participation in development communities is vital for national security.

This paradigm shift requires courage and vision. Public decision-makers, project managers, and innovation leaders within complex organizations must prioritize the adoption of open and secure technologies for their institutional portals.

But the transition to technological independence is a journey that should not be undertaken alone. SparkFabrik positions itself as a key technological partner in this transition, thanks to our proven experience in open source contribution, the development of secure Cloud Native architectures, and deep technical and strategic expertise in Drupal.

Contact us for a personalized consultation with our experts: it’s the first step to transforming regulatory challenges into extraordinary innovation opportunities.