What documents should I have ready before an NIS2 inspection?

At a minimum: information security policy approved by the management body, risk assessment, asset and supplier inventory, incident response procedures, business continuity and disaster recovery plans, evidence of management training, records of recent incidents and their notifications, and the latest internal or third-party audit report. Everything dated, version-controlled and signed off where required.

Who can answer the LibrePower 2026 survey?

Anyone who has worked with IBM Power, POWER, ppc64le, AIX, IBM i or Linux on Power in the last 24 months. Administrators, architects, DevOps engineers, pre-sales, ISVs, open-source maintainers, IBM Champions, Business Partners, researchers and hobbyists. The survey adapts to your profile and only shows you the sections that are relevant.

Is it really anonymous?

Yes. LibrePower only publishes aggregates with the number of responses (N) and never attributes anything to a person or company. Your email is optional and is only used to send you the report. Any direct quote from the comments requires explicit consent.

Do I lose my data and configuration when upgrading to Debian 13?

No, a dist-upgrade preserves data and configuration. Even so, a full backup or snapshot is mandatory as your rollback plan if anything fails during the upgrade.

How long does it take to upgrade from Debian 12 to Debian 13?

Between 20 and 60 minutes on a typical server, depending on the number of packages and disk and network speed. You should monitor the process to answer configuration prompts.

How long is Debian 12 Bookworm safe to keep running?

Debian 12 keeps LTS security support until roughly June 2028, but it has been oldstable since Trixie was released in August 2025. It is best to plan the upgrade with time to spare.

Does Wazuh support ISO 27001 compliance?

Yes. Wazuh maps to several Annex A controls in ISO 27001:2022, particularly A.8.15 (Logging), A.8.16 (Monitoring activities), A.8.8 (Management of technical vulnerabilities), and A.8.7 (Protection against malware). It provides technical evidence that auditors can review during certification.

What is Chain of Thought (CoT) in artificial intelligence?

Chain of Thought (CoT) is a technique that makes large language models (LLMs) generate visible intermediate steps before providing a final answer, simulating step-by-step reasoning. While it improves benchmark results, research from Apple, Arizona State and UC Berkeley demonstrates it is not genuine reasoning but a statistical constraint that mimics the form of human thought.

Do LLMs actually reason when using Chain of Thought?

No. CoT improves the internal coherence of generated text by forcing the model to produce sequential tokens with greater interdependence, but it does not imply genuine understanding. Arizona State University researchers showed that CoT performance collapses when the problem falls outside the training distribution, and a UC Berkeley paper revealed that only 2.3% of reasoning steps have real causal influence on the final answer.

What did Apple prove in their 'Illusion of Thinking' paper?

Apple showed that reasoning models collapse on complex problems such as the Tower of Hanoi. On easy problems, models without CoT are faster and more accurate. On medium problems, CoT pays off. On hard problems, both types fail, and CoT models shorten their chain of thought precisely when they should go deeper.

Is it worth paying for reasoning AI models?

It depends on the use case. For simple tasks, cheaper models outperform expensive ones. For medium-complexity tasks, CoT justifies the extra cost. For highly complex tasks, both types fail but the CoT model charges a premium. The recommendation is always to benchmark with your real-world data before choosing a model.

What is IBM Fusion CAS (Content Aware Storage)?

CAS is a capability built into IBM Fusion that turns storage into an active system: it extracts document content, generates vector embeddings, and keeps the index continuously updated through incremental processing — without moving data out of the storage layer.

What is the difference between a traditional RAG pipeline and CAS?

In a traditional RAG pipeline, data is copied from storage to an external processing system for vectorization. CAS integrates vectorization directly into the storage layer: zero-copy ingestion, incremental updates when documents change, and automatic inheritance of access control permissions on vectors.

Does CAS replace Docling and Milvus?

It depends on scale. For deployments with a few hundred documents that rarely change, a pipeline with Docling + Milvus works well. CAS is designed for environments with tens of thousands of documents that evolve daily, where maintaining a hand-built pipeline becomes a project in itself.

Does IBM Fusion CAS run on-premises?

Yes, the entire architecture runs on-premises: storage, GPUs, vectorization, and inference all within the organization's perimeter. Designed for GDPR, EU AI Act, and sector-specific regulation (healthcare, banking, public administration).

OWASP API Security Top 10 vs IBM API Connect

June 9, 2026/in News

API Security · OWASP · IBM API Connect

OWASP API Security Top 10 vs IBM API Connect.

The 10 critical API security risks per OWASP, one by one, mapped to real IBM API Connect and DataPower capabilities. Where the gateway solves it, where it helps, and where the work remains your backend's.

10 min read●Technical analysis●June 2026

APIs are the main attack vector against enterprise applications, and as AI agents and protocols like MCP gain adoption, the inventory of autonomous consumers keeps growing. The risks in the OWASP API Security Top 10 (2023 edition, current) don't change — they just become more critical.

This post gets straight to the point: a risk-by-risk mapping of what IBM API Connect + DataPower cover and what they don't. Out of 10 risks, the gateway has native coverage on 4, partial help on another 4, indirect impact on 1, and leaves 1 to the backend. Knowing which is which is what separates a trained team from one figuring it out in production.

Critical risks
in the OWASP list

2023

Latest current
OWASP edition

4 / 10

Native coverage
by IBM gateway

New categories
vs 2019

01 · Context

OWASP what, and why does it matter more in 2026?

The OWASP API Security Top 10 is the industry reference list of the 10 most critical API security risks. The latest edition is from 2023 — and in 2026 it remains the standard, with no new edition pending. What's changed is not the list, it's the context where it applies:

APIs remain one of the main attack vectors against enterprise applications.
Growing adoption of AI agents and protocols like MCP adds autonomous consumers to the picture — distinct from the apps and partners we've always had.
API sprawl — undocumented, ungoverned APIs — is still a recurring challenge in organisations with years of accumulated integrations.

In this scenario the gateway stops being just a proxy and becomes the piece where OWASP API Top 10 controls are enforced — or not.

How to read this post

Each risk carries a coverage badge with four levels: Native (the gateway covers it on its own), Partial (it helps but needs proper design), Indirect (limited contribution), or Not direct (the problem lives in the backend). The point isn't to sell — it's to know where to put the effort.

02 · The 10 risks

OWASP API Top 10 (2023) · mapped to IBM API Connect + DataPower

API1:2023 Broken Object Level Authorization (BOLA) Partial coverage

The client changes an ID in the URL (/orders/42 → /orders/43) and accesses an object that doesn't belong to them. Still the #1 risk — because object ownership logic lives in the backend.

What the gateway DOES Validates JWT, extracts user claims and passes them to the backend in signed headers. Can enforce policies by OAuth scope.

What your backend must do Check that the user_id in the token matches the owner of the requested object on every endpoint. The gateway doesn't know your data model.

API2:2023 Broken Authentication Native

Poorly validated tokens, insecure authentication mechanisms, JWTs signed with none, default credentials. Authentication is the plane where the gateway contributes most, no debate.

What the gateway DOES Full OAuth 2.0 (authorization server, scopes, refresh), JWT validation (signature, exp, aud, iss), OIDC, mTLS, rotating API keys, integration with external LDAP/AD/IAM. This is WD509G and WE752G territory.

What your backend must do Trust the gateway's validation result. If you re-validate at the backend, make sure not to introduce inconsistencies.

API3:2023 Broken Object Property Level Authorization Partial coverage

The backend returns more fields than the user should see (excessive data exposure) or accepts more fields than expected on write (mass assignment). Combines the former API3:2019 and API6:2019.

What the gateway DOES Response transformations (masking sensitive fields, scope-based filtering). DataPower can apply XSLT or GatewayScript policies to sanitise payloads.

What your backend must do Don't return fields the role shouldn't see. Don't accept unexpected fields on writes. The gateway can help after the fact, but the responsibility stays with API design.

API4:2023 Unrestricted Resource Consumption Native

Missing rate limiting, no quotas, payloads with no size cap. Used to be called "Lack of Resources & Rate Limiting". Where the gateway shines.

What the gateway DOES Rate limit per consumer, per plan, per endpoint. Daily/monthly quotas. Configurable throttling. Payload size limits. Burst control. All configured in the manager and enforced at DataPower or Nano Gateway.

What your backend must do Define the SLAs for each plan/consumer. The gateway enforces what you decide — it doesn't decide what's reasonable for you.

API5:2023 Broken Function Level Authorization Partial coverage

A normal user reaches admin endpoints because the API doesn't check the role beyond authentication.

What the gateway DOES Applies different policies per endpoint based on OAuth scopes. Blocks access to admin routes from tokens without the required scope. Conditional routing.

What your backend must do Design OAuth scopes properly from the start. An admin scope is useless if every flow grants it. The gateway enforces rules — it doesn't invent them.

API6:2023 Unrestricted Access to Sensitive Business Flows Partial coverage

An API exposes a sensitive business flow (purchases, transfers, voting) and an attacker automates thousands of legal but abusive calls. The damage isn't from a technical exploit — it's volume.

What the gateway DOES Per-consumer throttling, pattern detection, geo-blocking, CAPTCHA gateway integration, WAF integration (DataPower) for advanced rules.

What your backend must do Identify which flows are sensitive (not all are) and design business counters that the gateway can consume via analytics.

API7:2023 Server Side Request Forgery (SSRF) Not direct

An API accepts a URL from the user and uses it to make internal requests — the attacker uses it to hit your internal network. Vector on the rise in cloud due to metadata services (AWS IMDS, Azure IMDS).

What the gateway DOES Little directly. If the backend forwards outbound traffic through the gateway, you can restrict destinations. Not the usual pattern.

What your backend must do Validate incoming URLs against an allowlist. Block internal ranges (RFC 1918, link-local). Don't use user inputs directly in server-side HTTP requests. This is 95% backend.

API8:2023 Security Misconfiguration Native

Insecure defaults, misconfigured TLS, overly permissive CORS, missing security headers, stack-trace errors exposed. The classic that still causes incidents.

What the gateway DOES DataPower ships with secure defaults and allows centralised policies for TLS, CORS, security headers (HSTS, CSP, X-Frame-Options), stack-trace suppression. Unified configuration audit from API Connect V12.

What your backend must do Don't override at the backend what the gateway already does correctly (double-configuration errors). Keep secure defaults also inside the internal network.

API9:2023 Improper Inventory Management Native

Zombie APIs in production, old versions never retired, staging environments reachable from the internet, no documentation. The root of API sprawl.

What the gateway DOES API Connect's core is exactly this: API catalog, versioning, lifecycle (creation, publication, deprecation, retirement), federated governance in V12 (heterogeneous gateways visible from one control plane), Developer Portal with auto-generated documentation.

What your backend must do Follow the governance process: every published API goes through the manager. APIs not in the catalog are shadow — and those are the ones that lead to breaches.

API10:2023 Unsafe Consumption of APIs Indirect coverage

Your app consumes third-party APIs without validating what they return — and a compromised provider takes you down with them. New in 2023, especially relevant in architectures with many SaaS integrations.

What the gateway DOES If outbound consumption of external APIs goes through the gateway, you can apply schema validation, response sanitisation and rate-limit the provider. Not always the pattern.

What your backend must do Validate consumed API contracts. Don't trust received payloads. Isolate dependencies. This is development discipline, more than platform configuration.

03 · Visual summary

The 10 risks, at a glance

Coverage table of the IBM gateway (API Connect + DataPower) per OWASP risk:

Risk Short name Gateway coverage Key capability

API1

BOLA

Partial

JWT claims propagated

API2

Broken Authentication

Native

OAuth, JWT, OIDC, mTLS

API3

Object Property Level Authz

Partial

Field masking

API4

Unrestricted Resource Consumption

Native

Rate limit, quotas, throttling

API5

Function Level Authorization

Partial

OAuth scopes + policies

API6

Sensitive Business Flows

Partial

Pattern detection, WAF

API7

SSRF

Not direct

Backend primarily

API8

Security Misconfiguration

Native

TLS, CORS, headers, audit

API9

Improper Inventory Management

Native

Catalog, versioning, V12

API10

Unsafe Consumption of APIs

Indirect

Contract validation

Balance: 4 native coverage (API2, API4, API8, API9) · 4 partial coverage (API1, API3, API5, API6) · 1 indirect (API10) · 1 not direct (API7).

04 · The human factor

The gateway enforces rules — someone has to design them

The honest takeaway after reading the mapping is the one rarely surfaced in marketing material: the gateway is a powerful tool, but with no judgement of its own. It applies to the letter what your team configures. If OAuth scopes are poorly thought out, the gateway doesn't fix them. If you set a 10,000 req/s rate limit on a transfers endpoint, the gateway just helps you fail faster.

The capabilities of API Connect and DataPower are the ones you saw above. The difference between "we have API Connect" and "we have API Connect properly mitigating 8 of the 10 OWASP risks" comes down to the team operating it.

The 5 official courses that cover all of this WD509G and WD514G for the API Connect core; WE761G, WE752G and WE754G for DataPower. In English, in-company from 2 attendees.

Course catalog

What's in the courses

Not just "what each DataPower node does". It's when to apply which policy, how to design OAuth scopes that scale, when per-consumer rate limit falls short and business-flow throttling kicks in — the kind of operational decision you only see in projects, not in the manual.

Summary

The essentials in 5 points

Take-aways

→ OWASP API Top 10 2023 remains the current standard in 2026 — no pending re-edition, but more relevant with AI-agent adoption.

→ The IBM gateway (API Connect + DataPower) has native coverage on 4 risks — authentication, rate limiting, secure configuration and API inventory.

→ Partial help on another 4 (BOLA, property authz, function authz, business flows) — business logic stays in the backend.

→ SSRF and unsafe consumption are mostly developer territory — don't expect the gateway to solve them for you.

→ The difference between owning the tool and mitigating the risks is the team configuring it.

FAQ

Frequently asked questions

Is the 2023 OWASP API Top 10 still current in 2026?

Yes. The OWASP Foundation released the latest API Security Top 10 update in 2023 and no new edition has been published in 2026. The list remains the de facto industry benchmark — more relevant than ever with growing AI-agent API consumption.

Does API Connect / DataPower cover all 10 OWASP risks?

No, and that's not a gateway shortcoming. Out of 10 risks, the gateway has native coverage for 4 (API2, API4, API8, API9), partial coverage for 4 (API1, API3, API5, API6), indirect impact on 1 (API10) and leaves 1 to backend (API7 SSRF). The rest needs proper backend design and human review.

Which OWASP risk is easiest to mitigate with the gateway?

API4 (Unrestricted Resource Consumption) and API9 (Improper Inventory Management). Rate limiting, quota plans and throttling are API Connect's native territory. Catalogs, versioning and federated governance in V12 directly cover inventory management.

Where do I learn to configure all this in API Connect?

The official WD509G (admins) and WD514G (devs) courses, plus the DataPower ones (WE761G, WE752G, WE754G). SIXE delivers them in-company from 2 attendees with engineers who deploy these products in real customer environments. Full catalog at the API Connect training hub.

Sources

References

OWASP Foundation. OWASP API Security Project. owasp.org/www-project-api-security

OWASP Foundation. API Security Top 10 (2023 edition). owasp.org/API-Security · 2023 edition

IBM. IBM API Connect — Cloud Pak for Integration. ibm.com/products/api-connect

IBM. IBM DataPower Gateway. ibm.com/products/datapower-gateway

SIXE. Official IBM API Connect training hub. sixe.eu/education/ibm-api-connect

Last updated: June 2026.

API Connect & DataPower training

Let's talk about training for your team.

Tell us which OWASP risks worry you most, how many people are on your team and where you're based. We respond within 24 hours with an itinerary, format and closed quote. No endless forms.

See the full hub Contact

Informix 2026: v15, watsonx and 12.10 end-of-support

June 9, 2026/in News

Databases · IBM Informix · 2026

Informix in 2026: v15, watsonx and end of support for 12.10.

Three concrete movements — including an end-of-support that already kicked in — plus IBM's strategic push into analytics and AI. If you run Informix in production or are evaluating it, this is the map worth keeping current.

8 min read●Technical guide●June 2026

Informix is one of those databases people occasionally write off — and a couple of years later it's still in production across thousands of organisations running OLTP, time-series and IoT workloads. So far in 2026, three concrete things have happened that are worth knowing about.

At SIXE we deliver the three official Informix courses aligned with the v15 line, and we work with customers running Informix in production for years. Here's the useful recap: what's on the table, which dates matter, and where it fits.

Nov 2024

Informix 15
General availability

Jan 2026

Informix 14.10xC13
Latest fixpack

30-Apr-2026

EOS Informix 12.10
Already in effect

01 · What happened this year

Three movements on a single timeline

If you only have 30 seconds, this is the summary — the rest of the post unpacks each point:

Platform

Informix 15 consolidates the line

Removal of internal limits, storage up to half a yottabyte, external smartblobs and refreshed InformixHQ. The most relevant engine update in over a decade.

Maintenance

14.10xC13 (January 2026)

archecker now restores tables with SmartLOB (BLOB/CLOB) columns from backup. Direct I/O with 2K and 4K block sizes. Usual rollup of accumulated fixes.

Calendar

EOS of 12.10 — in effect

Informix 12.10 has been out of standard support since 30 April 2026. IBM offers Extended Support contractable through 2030 as a bridge for organisations that need one.

Status of vigent Informix versions in 2026 · Sources: IBM Support Lifecycle, IIUG.

02 · Platform

What Informix 15 brings

Version 15 — officially announced by IBM on 19 November 2024 — is the most significant engine update in over a decade. Key changes:

Storage without practical limits. A single Informix 15 instance can manage up to half a yottabyte of data. Removing the internal caps (rows per page, pages per partition, page sizes) means you no longer partition tables to work around the engine — you partition them when it makes functional sense.
External smartblobs. BLOBs and CLOBs (videos, documents, multimedia) can now live on an external filesystem. Faster backups and cheaper storage.
Refreshed InformixHQ. The graphical monitoring and administration tool gets easier Enterprise Replication configuration.
Better diagnostics. Improved SQL debugging to speed up developer work.

In plain English

For many Informix deployments, table partitioning was driven by the engine's internal limits rather than by business need. That changes with 15: you partition because it makes sense at the data-model level, not because the engine forces you to.

03 · Maintenance

What 14.10xC13 brings (January 2026)

If your organisation is still on the 14.10 line — and that's perfectly fine, it's still a supported release — the latest fixpack shipped in January brings:

archecker now restores tables with SmartLOB (BLOB / CLOB) columns from backup. Until now this scenario was more manual.
Direct I/O with 2K and 4K block sizes, on top of the previously available sizes. Finer control over I/O performance.
Usual rollup of accumulated fixes and stability improvements.

14.10xC13 is the maintenance release designed to keep the line healthy while you plan the jump to 15.

04 · AI integration

Informix in the watsonx.data ecosystem

IBM has published an official Informix connector inside watsonx, also documented in the watsonx SaaS docs portal. The value proposition:

Zero-ETL. The connector queries Informix data without replicating it to a separate data lake. One copy. IBM puts it literally: "access and query multi-modal data types in IBM Informix [...] with zero-ETL".
Open formats in watsonx.data. watsonx.data itself uses Apache Iceberg as an open table format to unify and share data across integrations (Db2, Netezza, Informix and others) without re-cataloging. Your data in Informix stays Informix.
Natural-language queries. watsonx.data's generative AI capabilities — per IBM — allow Informix customers to analyse data "using natural language with no SQL required".

For an organisation with Informix already installed, this integration turns the operational base into an analytical asset too — with no migration or replication.

How to position it

If your organisation is already using or evaluating watsonx.data, the Informix integration removes one of the typical objections: "how do I connect my operational data to the AI layer without setting up a separate pipeline".

05 · Calendar

Informix 12.10 — out of standard support since 30 April

Already in effect

Since 30 April 2026, Informix 12.10 (Enterprise, Workgroup and Express editions) is out of IBM standard support. Organisations still running 12.10 can contract IBM Extended Support with coverage through 2030 as a bridge. Without either, there are no security patches or incident resolution from IBM.

Practical implications:

The 12.10 line no longer accepts new license purchases.
Instances on 12.10 without an extension are without patches or official support since 30 April.
Extended Support is the contractable route to extend coverage through 2030 — useful as a bridge while planning migration.
The usual upgrade path leads to the latest supported release (Informix 15). 14.10 is a valid intermediate stop if application compatibility requires it.

Compatibility and suggested moves

Version Informix 12.10 Informix 14.10 Informix 15

IBM support

EOS 30-Apr-2026

Supported

Active line

Latest fixpack

xC16

xC13 · Jan 2026

Latest GA Nov-2024

Storage limits

Inherited

Removed

External smartblobs

Yes

watsonx.data integration

Limited

Yes

Suggested action

Exit plan

Upgrade plan

Target line

06 · Fit

Where Informix fits well in 2026

Scenarios where Informix remains a competitive option:

Intensive OLTP with low latency. Retail, point of sale, banking, telco — memory footprint and per-core performance remain among the best in the market.
IoT and time series. The engine supports temporal types and time-series management natively, without depending on external solutions.
Edge computing. Informix Embedded is designed for devices with constrained hardware and intermittent connectivity — kiosks, remote stores, industrial equipment.
Long-running databases. When you already have 12.10 or 14.10 in production, the natural path is to move up to 15 — keeping the team's knowledge, applications and existing integrations.

On top of that, the operational upside of a single vendor (IBM) for support, official training and partners with real production experience.

07 · Official training

The three courses we deliver

In SIXE's Informix training path we deliver the three official IBM courses aligned with version 15:

Code Course Level Duration

SIFMX819G

Informix 15 & 14.10 System Administration

Intermediate

3-4 days · 24h

SIFMX223G

Informix 14.10 for DBAs

Fundamentals

3 days · 24h

SXIFX15A

Informix 15 — Advanced Administration, Migration & Cloud

Advanced

3-4 days · 24h

Online or on-site, in English, with labs on real infrastructure. Delivered by the SIXE engineers who run Informix at customer sites. In-company from 2 attendees, with volume discount.

Summary

The essentials in 4 points

For people in a hurry

→ Informix 15 (Nov 2024) removes internal limits, adds external smartblobs and refreshes InformixHQ. Target line for migration.

→ 14.10xC13 (Jan 2026) brings SmartLOB restore via archecker and direct I/O in 2K/4K blocks. 14.10 remains a supported version.

→ 12.10 has been out of standard support since 30-Apr-2026. IBM Extended Support contractable through 2030 as a bridge.

→ watsonx.data integration with zero-ETL connector and open Iceberg format — operational data turns into analytical asset without replication.

FAQ

Frequently asked questions

Is IBM Informix still officially supported in 2026?

Yes. Informix 15 is the active line. Informix 14.10 is still a supported release receiving fixpacks (the latest, xC13, shipped in January 2026). Informix 12.10 has been out of standard support since 30 April 2026; IBM offers Extended Support contractable through 2030 for organisations that need to extend coverage.

Does the watsonx.data integration require moving data elsewhere?

No. The zero-ETL connector accesses Informix wherever it lives (on-premises, cloud, hybrid) without replicating data. One copy, two consumption planes: operational and analytical.

What is HCL's relationship with Informix?

HCL and IBM have co-licensed Informix since 2017. Both IBM Informix and HCL Informix exist with the same technical base and equivalent version numbers (15.0). SIXE's official courses are IBM.

Is it worth migrating to Informix 15 if I'm on 14.10?

Worth planning. The structural changes (removal of internal limits, external smartblobs) are significant, and the watsonx.data connector is aligned with the active line. 14.10 is still a supported release, so the jump can be planned without rush.

I'm on Informix 12.10. What now?

Standard support ended on 30 April 2026. Options are to contract IBM Extended Support (coverage through 2030) as a bridge, or to plan migration. Upgrading to the latest supported release (15) is the usual path; 14.10 works as an intermediate stop if application compatibility requires it.

Sources

References

IBM. Informix 15: Unparalleled Scalability for the Modern Data-Driven World. ibm.com — Informix 15 announcement

IBM. IBM Informix Enterprise Edition 12.10.x — End of support. ibm.com/support — 12.10 EOS

IBM. Fix list for Informix Server 12.10.xC16 (last fixpack). ibm.com/support — 12.10.xC16

IBM. IBM Informix connection — watsonx documentation. dataplatform.cloud.ibm.com — Informix connector

IBM. watsonx.data SaaS — Informix connection docs. ibm.com/docs — watsonx Informix

IBM. Official product page. ibm.com/products/informix

IIUG. International Informix Users Group — End of support dates. iiug.org — EOS dates

Last updated: June 2026.

Informix support & training

Migration, team training or just exploring? Let's talk.

12.10 → 15 migration, healthcheck of production instances, ongoing support and official training. SIXE engineers with real Informix in customer environments — no helpdesks, no ticket queues.

Contact SIXE See training

NIS2 inspections in 2026: what auditors look for

June 8, 2026/in cybersecurity, News

Compliance · Cybersecurity · EU Directive

NIS2 inspections in 2026: what auditors actually look for.

The supervision phase of NIS2 has begun across the EU. The conversation has shifted from "are we in scope?" to "can we show evidence?". This piece is the operational guide we run with clients when they have a competent authority on the calendar — what gets asked first, what documents to keep ready and where teams trip up.

8 min read●Operational guide●June 2026

NIS2 is no longer a planning exercise — it is an inspection regime. The Directive (EU) 2022/2555 entered into force in January 2023 and the transposition deadline was 17 October 2024; the supervisory framework described in Articles 31–33 became applicable in each Member State through national transposition measures. What was acceptable as "we are preparing" in 2024 now needs to be "here is the evidence" in 2026.

This is not a legal article (I am not a lawyer and I will not pretend) and it is not a fear-marketing piece. It is the operational checklist we walk through with clients who have either had a notification from their authority or who simply want to be inspection-ready before one arrives. If you already know what NIS2 is and how Wazuh maps to Article 21, our existing piece on NIS2 compliance with Wazuh covers that ground. This one is about the visit itself.

In 30 seconds

An NIS2 inspection focuses on evidence, not intent. Expect the competent authority to ask for: (1) the security policy approved by the management body (Art. 20), (2) the risk assessment, (3) the asset and supplier inventory, (4) SIEM telemetry and a real incident timeline showing the 24h / 72h / 1 month reporting process (Art. 23), and (5) proof of executive training. Documents undated, MFA absent on privileged access or notifications missed are the red flags that trigger deeper audits.

Minimum measure areas
Article 21(2)

24 / 72 h

Incident reporting
timeline (Art. 23)

Up to €10M / 2 %

Max admin fine
essential entities (Art. 34)

01 · The 2026 shift

From preparation to evidence

2024 was about scoping. 2025 was about building. 2026 is about showing. Once national transposition laws came into force, the supervisory regime described in Articles 31 to 33 of NIS2 became operational. Competent authorities can now request information, perform on-site inspections and apply the administrative measures in Article 32 — including, in serious cases for essential entities, the temporary disqualification of an individual from management functions (Art. 32.5).

The good news: the criteria have not changed. Article 21 is still Article 21. The bad news: you can no longer answer "we are implementing it" with a smile. Inspectors want documented, dated, version-controlled artefacts.

A note on the UK

The UK is outside NIS2's direct scope (post-Brexit) and operates its own NIS regulations, with a proposed Cyber Security and Resilience Bill intended to update them — its status may have evolved by the time you read this. UK organisations with EU subsidiaries, however, are still in scope through those EU entities, and many follow NIS2 as a de facto baseline regardless.

Article 21(2) at a glance

For reference, the ten minimum measure areas the directive requires (verbatim short-form): risk analysis and information system security policies · incident handling · business continuity (backups, disaster recovery, crisis management) · supply-chain security · security in network and information system acquisition, development and maintenance (incl. vulnerability handling) · policies to assess the effectiveness of risk-management measures · basic cyber hygiene practices and training · cryptography and, where appropriate, encryption · human-resources security, access control and asset management · multi-factor or continuous authentication and secured communications.

02 · Who supervises you

Identifying your competent authority

Article 8 requires each Member State to designate one or more competent authorities for NIS2 supervision. In practice, the model varies by country: some have a single national agency for all sectors, others split supervision between the national cybersecurity agency, the financial regulator, the energy regulator, the health regulator, etc. Banking and financial-market entities also intersect with DORA (Regulation (EU) 2022/2554), where DORA generally prevails as lex specialis for what it covers.

Before anything else: confirm who supervises you and how they communicate. Most authorities have published an entry portal — find it now, not on the day the email lands.

03 · The first five questions

Five things an inspector typically checks first

While supervisory practices vary by Member State and sector, these are the artefacts most commonly requested in readiness reviews and regulatory audits — and the ones that, in our experience, tend to make the rest of the conversation much shorter when in order.

What is requested

What "good" looks like

Security policy approved by the management body

Dated document with a board-level signature and a minute referencing the approval. References Article 21(2) areas explicitly.

Risk assessment and treatment plan

Methodology declared (ISO 27005, NIST 800-30, etc.), recent (last 12 months), with residual risk accepted in writing by the responsible person.

Asset and supplier inventory

Asset list including criticality; supplier list flagging critical ICT providers with the NIS2 contract clauses (notification, audit rights, exit plan).

Incident response procedures and a real-world timeline

Documented procedure plus a sanitised post-mortem of a recent incident showing the 24h / 72h / 1 month steps with timestamps from the SIEM.

Evidence of executive training (Art. 20.2)

Attendance records of cyber training delivered to the management body in the last 12 months, including content and provider.

04 · The clock

The 24 / 72 / 1 timeline you will have to demonstrate

Article 23 sets three reporting steps for significant incidents. Inspectors do not just ask whether the policy exists — they ask to see a real timeline: when the incident was detected, when the early warning was filed, when the notification was filed, and how you got there. Without centralised telemetry, that timeline is unreconstructable.

Significant incident reporting · Article 23

24 h

Early warning

Indicating any suspicion of malicious origin or cross-border impact.

72 h

Incident notification

Initial assessment, severity, IoCs and mitigation steps already taken.

1 month

Final report

Root cause, mitigation actions and cross-border impact where applicable.

The piece that holds NIS2 together

Detection without analysts is theatre. We typically combine Wazuh deployment (open-source SIEM/XDR with NIS2-mapped dashboards, zero licence cost) with 24/7 emergency support attended in English, Spanish and French — that combination is what materially sustains the Article 23 timeline. If you need an enterprise commercial SIEM with deeper integrations, we also deploy IBM QRadar.

05 · The folder

The "inspection-ready" folder

Keep these in a single, controlled repository — not in someone's personal mailbox. Dated, versioned, owner assigned.

Information security policy (board approved)

Risk assessment and treatment plan

Asset inventory with criticality

Critical ICT supplier register + NIS2 clauses

Incident response procedure + runbooks

Business continuity and DR plans

Backup strategy + last restore test record

Vulnerability management policy and reports

MFA enforcement evidence on privileged access

Executive training records (Art. 20.2)

Recent incident notifications filed

Latest internal or third-party audit report

Mapped against Article 21(2) measure areas of the Directive (EU) 2022/2555.

06 · Quick check

Are you inspection-ready? Three quick questions

A rough self-check based on the three issues we see most often in pre-audit reviews. It is indicative, not a formal assessment.

Inspection-readiness check

3 questions · instant result · no tracking

1. Has your management body formally approved the information security policy in the last 12 months — with a minute or attestation on file?

2. If a significant incident happened today, could you produce a SIEM timeline with timestamps for the 24h / 72h / 1-month reporting steps?

3. Is MFA enforced on all privileged and remote access, with evidence in your IAM or SSO logs?

You look inspection-ready on the basics.

The three areas inspectors check first are in order. Worth investing the next round in tabletop exercises, supplier-clause review and refining the incident timeline templates.

→ Talk to SIXE about a tabletop exercise

Visible gaps to close before an inspection.

The pieces are there but not inspection-grade. Typically a focused two-month sprint — formalising the policy sign-off, rehearsing the incident timeline and completing MFA coverage — gets you across the line.

→ See how Wazuh closes the SIEM evidence gap

Material risk in an inspection today.

Missing board approval, no SIEM timeline and patchy MFA together are exactly what triggers a deeper audit. Prioritise these three before anything else — the rest of the artefacts matter less if the basics aren't there.

→ Request a NIS2 readiness review

07 · How we help

What SIXE puts on the table

NIS2 inspection-readiness is about disciplined instrumentation and documented operation. Each of the seven pillars below has a concrete piece we deploy in client engagements:

Gap assessment against Article 21 — mapping existing ISO 27001 / NIST CSF / ENS controls and producing the inspection-ready artefacts.
Governance and executive training — wording for the board approval minute, training content for management bodies (Art. 20.2 evidence).
SIEM / XDR. Wazuh deployment with NIS2-mapped dashboards is our default — open source, zero licence cost. If you need a commercial enterprise platform with deep integrations we also deploy IBM QRadar.
24/7 incident response. Detection without analysts cannot hold the 24h clock. Emergency 24/7 support attended in English, Spanish and French — no intermediaries, no ticket carousels.
MFA enforcement. Particularly painful in IBM Power estates — PowerSC for AIX and IBM i covers that layer with compliance integration.
Supplier register and contract clauses. Critical ICT provider inventory and NIS2-aligned clauses — the supply chain measure (4) is where most teams fall short.
Tabletop exercises and incident timeline rehearsal. The first time you reconstruct a 24h / 72h timeline shouldn't be during an actual incident.

If your sector is industrial (energy, water, transport, manufacturing or any OT-heavy environment), there is an extra layer that does not appear in generic ISO frameworks: OT visibility. We use Claroty for OT network monitoring and industrial device auditing with Tenable.

FAQ

Quick questions

Who is my competent authority under NIS2?

Each EU Member State designates one or more competent authorities per sector (Article 8). The authority depends on your sector and country — in some countries a single national agency covers everything, in others supervision is split between the national CSIRT, the financial regulator, the energy regulator, etc. Check your national NIS2 transposition law or the national CSIRT's website. ENISA publishes consolidated information on national contact points and supervisory authorities across Member States.

How does an NIS2 inspection typically start?

For essential entities, supervision is proactive (Art. 32): the authority can launch an inspection without prior indication of non-compliance. For important entities, supervision is reactive (Art. 33), usually triggered by an incident report or a complaint. In both cases the authority gives written notice, requests an initial information package and may schedule on-site visits.

What documents should I have ready before an inspection?

At a minimum: information security policy approved by the management body, risk assessment, asset and supplier inventory, incident response procedures, BCP/DR plans, evidence of management training, records of recent incidents and their notifications, and the latest audit report. Everything dated, version-controlled and signed off where required.

Does the inspector ask for SIEM evidence?

Yes. Expect requests for: list of monitored assets, sample alerts and how they were triaged, log retention configuration, integrity of audit trails, dashboards mapped to NIS2 controls, and the timeline of a real incident showing the 24h/72h reporting steps from Article 23. Wazuh covers this with NIS2-aligned dashboards.

What are the red flags that trigger a deeper audit?

No documented risk management framework. Management body has not formally approved security policies (a direct breach of Art. 20). No MFA on privileged access. Incident notifications missing the 24h/72h deadlines. No incident drill in the past 12 months. Supplier inventory missing critical ICT providers. Audit evidence sitting in personal email instead of a controlled repository.

Is ISO 27001 enough to pass an NIS2 inspection?

ISO 27001 is a strong base — most Article 21 measures are covered — but it is not an automatic NIS2 conformity mark. You need to map your existing controls to Art. 21, document the gaps (typically 24h/72h notification process, supply chain clauses, executive training) and produce inspection-ready evidence for each.

NIS2 inspection-readiness

We help you walk into the inspection prepared

From the readiness review against Article 21, to the SIEM evidence that holds the 24/72h timeline, to a 24/7 team for when something breaks at three in the morning. Fifteen-plus years in critical-infrastructure cybersecurity, IBM Business Partner, attended in English, Spanish and French — no intermediaries.

Request readiness review → Wazuh deployment 24/7 emergency support

If open source on IBM Power is in your job, this is for you

June 8, 2026/in News

Community · Open Source · IBM Power

LibrePower 2026: the annual survey on open source in IBM Power.

AIX, IBM i, Linux on Power, ppc64le. 12–20 minutes of your experience turn into an annual public report that helps everyone understand, with real data, where the ecosystem actually stands. We're helping spread the word from SIXE so it reaches more people.

5 min read●Survey open●June 2026

LibrePower 2026 annual survey poster on open source in IBM Power

Survey open at librepower.org/annual-survey

LibrePower has just opened its annual survey on the state of open source in IBM Power, and anyone who works with the platform can answer it — AIX and IBM i administrators, Linux on Power teams, ppc64le developers, architects, pre-sales engineers, ISVs, IBM Champions and Business Partners. The output is a public annual report that gives a useful, aggregated picture of what's working well, what's harder than it should be, and what the community sees as the real priorities.

"If IBM Power shows up anywhere in your job, this survey is for you."

— LibrePower 2026

What is LibrePower and why take part?

LibrePower is an independent project focused on the open-source ecosystem around IBM Power. Its main output is a yearly public report on how the platform is doing from the point of view of the people who actually operate and build on it: the AIX admin maintaining Toolbox packages, the IBM i shop bringing modern tooling on board, the engineer building Python wheels for ppc64le, the architect sizing up a new workload for Power.

Between surveys, LibrePower runs a technical newsletter on Substack with benchmarks, ppc64le porting notes and IBM Champions interviews. It works as a complement to the official channels and the vendor blogs — an additional view from the technical community itself.

Why it matters

A report grounded in real community responses gives useful context to everyone: for the people using the platform, the people building on it and the people deciding what to prioritise. The more diverse the sample, the more representative the result.

Are you the target audience? Almost certainly yes

The survey adapts to your profile: you only see the questions that make sense for the platforms you work with. If you work with IBM i, the AIX questions never appear. If you do Linux on Power, you don't get asked about VIOS. And if your only contact with the platform is following the ecosystem from the outside, there's a path through for you too.

It's designed to cover the full spectrum:

Operations — L1, L2, L3 admins on AIX, IBM i, VIOS and Linux on Power. The people who actually pick up the phone when production moves.
Development and platform — ppc64le developers, DevOps/SRE teams, open-source maintainers, engineers porting stacks to Power.
Architecture and pre-sales — anyone deciding between Power and other platforms, designing migrations, or walking customers through the technical choice.
ISVs, IBM Business Partners and IBM employees — the voice of the people building and selling on the platform counts just as much as the voice of those running it.

What you'll be asked

The areas LibrePower 2026 covers

The survey is split into thematic blocks. You only see the ones that apply to your profile, so your actual journey is shorter than the full list:

Survey structure

You and your platformRole, environments you manage, workloads (Oracle, Db2, SAP, HANA, Java, containers, AI, HA/DR, modernisation…). Sets up the rest of the journey.

Your view from the fieldMaturity of open source on Power, recommendation (NPS 0–10), community health, skills market, real production usage patterns.

Openness by layerFrom the ISA to firmware, via documentation, distributions, containers and CI/CD. A matrix measuring how open each layer you actually touch is in practice.

AIX, IBM i and Linux on Power realityThree platform-specific blocks — you only see the one that applies. AIX Toolbox and dnf, IBM i RPMs via ACS, ppc64le on Linux, container ecosystem and CI.

Trust in each actorIBM, Red Hat, SUSE, Canonical, independent maintainers, ISVs, Business Partners. You only rate the groups you have a basis to judge.

Priorities and how to take partWhat LibrePower should tackle in the next 12 months, what's the #1 package or runtime to unblock, and how to get involved in the project if you want.

Why we're getting behind this at SIXE

As an IBM Business Partner focused on open source, Linux on Power, AIX, IBM i and the wider Power platform, we've watched the open-source layer keep growing across the ecosystem in recent years — from the official repositories, to the modern tooling landing on IBM i, to the steady evolution of ppc64le on Linux. What we see day to day in consulting and training is a useful complement to what comes through the official channels: concrete cases, real decisions, the kind of questions that show up in actual projects.

That's why we're spreading the word about the survey: the more diverse the sample, the more useful the report — and while we're at it, we'd love to see strong representation from across Europe and the broader international community.

If you want to see the kind of work we publish in this space: we installed and tested AIX 7.3, looked at what's new in IBM i 7.6, and compared alternative hypervisors to ESXi (PowerVM, Proxmox, OCP). We also offer official AIX training and consulting on Power, AIX, VIOS and PowerVM.

Three quick questions before you start

Is it in English?

Yes, the survey is fully in English. There's a free-text box at the end ("anything we should have asked?") where you can flag anything in your own language — that's exactly the kind of feedback that shapes the next edition.

What if I don't have experience in something specific?

Almost every question has an "N/A" or "don't know" option. The survey is designed for you to only weigh in when you have a basis to do so — that's precisely what gives the report its credibility.

Can I share the link with my team?

Yes, please. It's librepower.org/annual-survey. The more varied the profiles that respond, the more useful the report.

15 minutes · Report straight to your inbox

Answer the LibrePower annual survey

AIX, IBM i, Linux on Power, ppc64le. If you work with the platform in any layer, your experience makes the report better. Independent, anonymous by default, free for the whole community.

Take the survey → Subscribe to the newsletter Talk to SIXE

Ceph Storage News 2026: Latest Releases, Features & Roadmap

June 3, 2026/in News

Storage · Ceph · Open Source

Ceph in 2026: versions, roadmap, and production best practices.

Squid is stable. Tentacle is on the way. And the decisions you make about your storage architecture this year will define your infrastructure for the next five. This is everything you need to know — no vendor pitch, just engineering.

10 min read●Technical guide●June 2026

Ceph is the most mature and widely deployed open-source platform that delivers block, object, and file storage from a single cluster with no single point of failure. It is used in production by organisations managing petabytes of data — from research labs to cloud providers. With Tentacle (v20) now released and Squid (v19) still widely deployed, 2026 is a good year to understand where Ceph stands and where it's going.

At SIXE we've been deploying and supporting Ceph infrastructure in production for years. This page is the reference we wish existed when we started: current releases, real-world features, honest best practices, and zero marketing waffle.

v20

Latest release
(Tentacle)

3-in-1

Block + Object + File
from one cluster

Single points
of failure

01 · Overview

What is Ceph?

Ceph is a free, open-source software-defined storage platform that unifies object, block, and file storage in a single distributed cluster. Originally built by Sage Weil as part of his PhD at UC Santa Cruz, it is now maintained by a global community and commercially supported by IBM (as IBM Storage Ceph) and Red Hat (as part of OpenShift Data Foundation).

What makes Ceph different from traditional storage is its CRUSH algorithm: data is distributed across commodity hardware with no central metadata server, so the cluster can self-heal when a disk or node fails. No proprietary appliance, no vendor lock-in, no silent single point of failure waiting to ruin your quarter.

If you're evaluating alternatives, our Ceph vs Storage Scale (GPFS), NFS, and GFS2 comparison covers the trade-offs. For object storage specifically, see Ceph vs MinIO.

In plain terms

Ceph doesn't care how many disks you have or where they are. You add hardware, Ceph redistributes the data. You lose hardware, Ceph rebuilds automatically. That's the entire value proposition, and it's a good one.

02 · Releases

Ceph version history

Ceph follows a predictable release cadence with major versions every 12–18 months, each named alphabetically after a marine creature. Here's where things stand:

ReleaseTentacle (20.x)Squid (19.x)Reef (18.x)

Released

Nov 2025

Mar 2024

Aug 2023

Status

Active / Recommended

Active

End of life

OSD engine

Crimson maturing

Crimson early adoption

Classic OSD

Key feature

EC Crimson, tiering, MDS

RGW perf + CephFS NFS

RBD mirroring

Upgrade path

Current target

→ Tentacle

→ Squid → Tentacle

Quincy (17.x) reached end of life in 2025. If you're still running it, the upgrade path is Quincy → Reef → Squid → Tentacle. The official upgrade docs walk through the process step by step. Full changelogs are on the Ceph releases page.

Recommendation

Don't skip versions. Ceph only supports sequential upgrades (Quincy → Reef → Squid). Planning the jump before your current version hits end-of-life is considerably cheaper than doing it under pressure.

Ceph release timeline — sequential upgrades only. Each major version is supported for approximately 2 years.

Ceph provides block, object, and file storage through a single RADOS cluster. Each interface serves different workloads, all sharing the same self-healing infrastructure.

03 · What's new

Ceph Squid (v19): the current stable release

Squid is a meaningful step forward in both performance and operational maturity. The headline features:

Crimson OSD: early adoption

The Crimson OSD is a ground-up rewrite of the classic Object Storage Daemon using the Seastar framework. It replaces the traditional multi-threaded architecture with a shared-nothing, run-to-completion model. Translation: significantly lower latency on NVMe-backed clusters, especially for the small random I/O patterns typical of databases and virtualisation workloads. Crimson continues to mature across releases — it's available for early adoption in specific scenarios, but the classic OSD remains the default for most production deployments.

RADOS Gateway performance

The S3-compatible object layer got faster multipart uploads, better garbage collection, and lower memory consumption under heavy PUT workloads. If you're using Ceph as a data lake for AI training sets or as a backup target, this is the kind of unsexy improvement that saves you real money at scale.

CephFS + NFS-Ganesha

CephFS gained better NFS export support via NFS-Ganesha, improved snapshots, and more granular quotas. We've written a detailed guide on high-availability NFS with Ceph and Ganesha if you're running this in production.

Dashboard refresh

The built-in web management UI got a facelift, better Prometheus alerting integration, and new pages for RBD mirroring and CephFS subvolumes. Still not going to win design awards, but it does the job.

04 · Latest release

Ceph Tentacle (v20): the latest generation

Tentacle was released on 18 November 2025 and is now the recommended version for new deployments. Its key improvements over Squid:

Crimson for erasure-coded pools — expanding Crimson's performance benefits beyond replicated pools to cost-efficient bulk storage.
Smarter RADOS tiering — better data placement policies for hybrid clusters mixing NVMe, SSD, and HDD.
RGW encryption improvements — more granular bucket-level key management with external KMS integration.
MDS at scale — better metadata server performance for clusters with billions of files.

Full release notes are on the Ceph releases page. Track ongoing development on the Ceph project tracker and the ceph-devel mailing list.

Worth noting

If you're running Squid in production and it's stable, there's no rush to jump to Tentacle immediately. But for new deployments, Tentacle is the recommended starting point — you get all of Squid's improvements plus the Tentacle enhancements from day one.

05 · Kubernetes

Rook-Ceph: storage for Kubernetes clusters

Rook is the CNCF-graduated operator that deploys and manages Ceph natively inside Kubernetes. If you're running containerised workloads, Rook-Ceph is the standard way to get persistent storage without leaving the Kubernetes ecosystem.

Recent Rook releases have focused on operator stability, smoother OSD scaling (adding or removing disks is less disruptive now), better Helm chart defaults for production, and tighter integration with OpenShift Data Foundation.

For teams on Red Hat OpenShift on IBM Power, Rook-Ceph provides a solid path to persistent storage. SIXE offers Ceph training courses covering both standalone admin and Rook-based deployments. If you're starting from scratch, our guide on how to learn Ceph maps out a structured path.

06 · Use cases

Ceph features and use cases

One cluster, three interfaces. That's Ceph's party trick — and it's a genuinely useful one. Each access layer serves a different type of workload:

Three interfaces, one cluster

■

RBD — Block StorageVirtual disks for VMs (Proxmox, KVM, OpenStack) and Kubernetes PVs. Thin provisioning, snapshots, clones, and cross-site mirroring for DR.

■

RGW — S3 Object StorageS3-compatible REST API. Backup targets, AI/ML training datasets, media repositories, data lakes. See our Ceph vs MinIO comparison and IBM COS migration guide.

■

CephFS — POSIX File SystemShared file access for HPC, CI/CD pipelines, and content platforms. Multi-filesystem support, quotas, snapshot-based backups.

■

Emerging: AI InfrastructureS3 for model/dataset distribution + RBD for GPU-attached volumes. See our analysis on Storage Scale vs Ceph for AI inference and vLLM on IBM Power.

Why this matters

Most storage solutions force you to choose: block OR object OR file. Ceph does all three from a single pool of hardware. That's fewer systems to operate, fewer vendors to manage, and fewer 3AM calls about the storage array you forgot existed.

07 · Adoption

Who uses Ceph in production?

Ceph isn't a lab experiment — it runs critical workloads at scale. Cloud providers use it for multi-tenant infrastructure, research institutions for petabyte-scale data lakes, and enterprises for unified storage behind Kubernetes and OpenStack. CERN, Bloomberg, Deutsche Telekom, DigitalOcean, and OVHcloud are among the publicly known large-scale adopters.

The most common deployment scenarios we see at SIXE:

Cloud infrastructure — backend storage for OpenStack or Kubernetes, replacing proprietary SANs.
AI/HPC pipelines — S3 object storage for training datasets, block storage for GPU-attached compute nodes.
Backup and archiving — erasure-coded object storage replacing tape or proprietary deduplication appliances.
Enterprise file shares — CephFS + NFS-Ganesha replacing traditional NAS for departmental shares.

Platform compatibility

PlatformCompatibleIntegrationNotes

Kubernetes

Yes

Rook (CNCF)

CSI native, dynamic PV

OpenShift

Yes

ODF / Rook

Red Hat supported

Proxmox

Yes

Built-in

RBD + CephFS native

OpenStack

Yes

Cinder / Glance / Manila

De facto standard

VMware

Yes

iSCSI gateway

Not native, via gateway

Nutanix

Partial

iSCSI

Nutanix has own storage

08 · Best practices

Ceph best practices in 2026

Deploying Ceph is not hard. Deploying Ceph well is where the difference is between a cluster that hums along for years and one that keeps you up at night. Here's what actually matters:

Hardware sizing

OSDs: Dedicate NVMe SSDs for the WAL/DB partition, even if the main OSD disks are HDDs. This single change can double your random write performance.
Network: 10 Gbps minimum for the public network, separate 10 Gbps (or higher) for the cluster/replication network. Network is almost always the bottleneck — not CPU, not memory.
Memory: Plan for 4–5 GB RAM per OSD daemon. BlueStore on NVMe may need more.

Configuration

Replication vs erasure coding: Use replication (3x) for latency-sensitive workloads (RBD, CephFS). Use erasure coding for bulk storage (RGW backups, archives). Don't guess — profile first.
CRUSH map: Design it to reflect your physical failure domains (rack, row, datacenter). The default config assumes all OSDs live in one happy failure domain. They don't.
Monitoring: Ceph Dashboard + Prometheus + Grafana. Configure alerts for OSD down events, nearfull thresholds, and slow ops. If your cluster can page you before users notice, you're doing it right.

Common pitfalls

The most common Ceph error we see in production — could not connect to ceph cluster despite configured monitors — has a surprisingly simple fix most of the time. Our Ceph troubleshooting guide walks through it and the other usual suspects step by step.

The one rule

Never let a Ceph cluster get above 85% capacity. CRUSH rebalancing becomes increasingly painful as you approach full. You won't notice the problem gradually — you'll notice it all at once. Plan your expansion before you need it.

09 · Alternatives

Ceph vs the rest: a quick comparison

Every storage solution has trade-offs. Here's an honest snapshot — no shade at anyone, just different tools for different jobs:

CephMinIOIBM Storage Scale

Storage types

Block + Object + File

Object only

File + Object

Protocol

S3, NFS, iSCSI, RBD

POSIX, NFS, S3

Complexity

Medium–High

Low

High

Kubernetes native

Rook (CNCF)

Operator

CSI driver

Licence cost

Open source

Commercial

Best fit

Unified infrastructure

Pure S3 workloads

HPC / AI at scale

Need the full picture? Our detailed analyses go deeper: Ceph vs MinIO and Ceph vs Storage Scale (GPFS).

10 · Expert support

Need help with Ceph in production?

Reading docs is one thing. Running a Ceph cluster under SLA with actual data that matters is another conversation entirely. SIXE is an IBM Business Partner with hands-on experience designing, deploying, and operating Ceph infrastructure across Europe.

Consulting & deployment — Architecture design, hardware sizing, CRUSH map optimisation, and production hardening.
Official Ceph training — From standalone admin to Rook-based Kubernetes deployments, with hands-on labs.
Ongoing support — Monitoring, upgrades, troubleshooting. Senior engineers, no helpdesks.
AI/HPC storage consulting — Ceph architectures for machine learning pipelines and high-performance computing.

Engineering you can talk to

We're the team you call when the cluster is on fire — and the team you should have called before it caught fire. Tell us about your project and we'll tell you what it actually takes.

Summary

The essentials in 5 points

If you're in a hurry

→ Ceph Tentacle (v20) is the latest release (Nov 2025), with erasure-coded Crimson, smarter tiering, and improved MDS performance.

→ Squid (v19) remains a solid active branch — widely deployed, with Crimson OSD early adoption, faster RGW, and better CephFS/NFS support.

→ Reef (v18) has reached end of life — final release 18.2.8 shipped March 2026. Plan your upgrade to Squid or Tentacle.

→ Rook-Ceph remains the standard for Kubernetes-native Ceph deployments, now with smoother scaling.

→ Three interfaces from one cluster: block (RBD), object (RGW), and file (CephFS) — the most mature open-source unified storage platform available.

FAQ

Frequently asked questions

What is the latest stable version of Ceph?

Ceph Tentacle (v20.x), released in November 2025. Squid (v19.x) is also an active stable branch and remains widely deployed. Reef (v18.x) reached end of life with its final release (18.2.8) in March 2026 — new deployments should target Squid or Tentacle.

Can Ceph replace NFS in production?

CephFS can serve NFS exports via NFS-Ganesha, and it works well in production. But Ceph is not a drop-in NFS replacement — it requires cluster planning, network design, and operational know-how. It's a different animal.

Is Ceph suitable for production workloads?

Yes. Ceph runs in production at organisations managing petabytes of data, from research institutions to cloud providers. It is commercially supported by IBM and Red Hat.

What is the difference between Ceph and MinIO?

Ceph provides block, object, and file storage from one cluster. MinIO focuses exclusively on S3-compatible object storage. Ceph is more versatile but operationally more complex; MinIO is simpler for pure object storage workloads. Both are excellent — different tools, different trade-offs.

How does Rook-Ceph work with Kubernetes?

Rook is a CNCF-graduated operator that automates Ceph deployment, scaling, and upgrades inside Kubernetes. It provides CSI-based dynamic provisioning for RBD and CephFS volumes — you create a PVC, Rook handles the rest.

Sources

References

Ceph. Official documentation and release notes. docs.ceph.com/releases

Ceph. Project homepage and downloads. ceph.io

Rook. Cloud-Native Storage for Kubernetes. rook.io

IBM. IBM Storage Ceph. ibm.com/products/storage-ceph

Red Hat. Red Hat Ceph Storage. redhat.com/technologies/storage/ceph

Last updated: June 2026.

Ceph infrastructure support

Need Ceph in production? Let's talk architecture.

Cluster design, deployment, training, and ongoing support. Senior storage engineers across Europe — no helpdesks, no ticket queues. Just people who know Ceph.

Contact SIXE +34 91 198 02 43

VMware in 2026: Four Paths After the Broadcom Model Change

May 28, 2026/in News

Virtualization · Infrastructure · 2026

VMware in 2026: four paths after the Broadcom model change.

If your vSphere 7 or 8 is humming along, you have zero reason to touch it. Period. What changed is the licensing model, not the platform — and there are four reasonable paths: stay with Broadcom, keep what you have with third-party support, migrate to Proxmox VE, or jump to OpenShift Virtualization. The decision about when — or if — you upgrade is back on your side. We run any of the four.

10 min read●Guide●May 2026

30-second TL;DR: four reasonable paths for your VMware in 2026 — stay with Broadcom (VCF/VVF), keep your vSphere on third-party support, migrate to Proxmox VE, or move to OpenShift Virtualization. All four work; the fit depends on your stack, your timeline, and how much budget you feel like committing to the vendor.

We've been running VMware since before Broadcom existed, and since Broadcom exists. We also do third-party support for enterprise software, migrations to Proxmox and OpenShift, and official training in whatever you need. No favourite horse — just very different customers, and this post is what we tell them when they ask "OK, so what do I do?".

Reasonable paths
in 2026

2023

Broadcom completes
VMware acquisition

15+

Years of SIXE
in enterprise virtualization

01 · Context

What changed at VMware after the Broadcom acquisition?

Broadcom closed the VMware acquisition on November 22, 2023. From that point, several things changed on the commercial side — outlined in Broadcom's official portfolio changes article. The technical platform is still the same. What changed is how you buy it, not how it runs.

New perpetual licenses are gone. The catalog switched to subscriptions, mainly through two bundles: VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF).
Catalog reorganized. Products previously sold separately (vSAN, NSX, Aria) are now integrated into the bundles, which changes the per-server licensing math.
Partner program reset. Channel agreements were renegotiated and many customers now deal directly with Broadcom or with a tier-one partner.
Existing perpetual licenses remain valid: customers who already bought them can keep running them, though without new updates if they don't keep a support contract.

In context

It's a commercial-model change, not a technical fault in VMware. For some organizations the transition is manageable; for others — especially those that don't use all bundle components — the bill multiplies. Do the math before you renew, not after.

02 · Decision

Why are so many companies rethinking VMware in 2026?

We hear it in almost every conversation — three reasons that usually show up together:

The bill goes up. Switching to a bundle with components you don't use (vSAN, NSX, Aria) multiplies the per-core cost.
The clock is ticking. Multi-year contracts expiring, and the classic email of "your renewal is in 90 days, please confirm".
The platform is aging. vSphere 7 reached End of General Support on October 2, 2025; vSphere 8 is scheduled for 2027.

Not everyone experiences this the same way. If you have 3 hosts and a modest cluster, the adjustment is manageable. If you have 300 hosts with stretched vSAN, opening the option set has a clear and quick return. The question is no longer "which version do I buy?" — it's now "what do I do with everything I already have deployed and running?".

03 · The four paths

What are your four real options in 2026?

There are four reasonable paths today. There's no universal answer: the fit depends on how much VMware you have, what runs on top of it, who operates it, and what timeline you're managing.

Option Who it fits What you gain What it costs

1. Stay with Broadcom (VCF / VVF)

You actually use the full bundle (vSAN, NSX, Aria) and have budget for the new subscription model.

Complete platform, official roadmap, direct vendor support, access to new versions.

Annual subscription, bill tied to core count.

2. Keep your VMware with third-party support

You're stable on vSphere 7 or 8 and want to stay that way for several more years — with savings on licensing and autonomy over when (or if) to migrate.

Current version kept secure and operational; contractual SLA; budget freed for investment or headcount; time to evaluate Proxmox or OpenShift without pressure.

No new vendor versions, no direct Broadcom support while the contract lasts.

3. Migrate to Proxmox VE

Teams looking for a general-purpose open source hypervisor equivalent to vSphere for VMs and LXC containers.

Open platform, no per-host licenses, optional enterprise support subscriptions, mature ecosystem.

Migration project (P2V/V2V), team re-skilling, some automation rewrites.

4. Migrate to OpenShift Virtualization

You're already heading toward containers and Kubernetes and want to consolidate VMs and pods on a single platform.

One platform for VMs and containers, native CI/CD and Kubernetes networking integration, Red Hat / IBM enterprise support.

Kubernetes adoption curve, network and storage redesign, wave-based migration plan.

All four work. What we do NOT recommend: deciding against the clock with the renewal looming. In that scenario you almost always end up renewing by default, without having compared anything — and that's the worst option of all, because you didn't even choose it.

Interactive

Which path fits you?

Three quick questions and we'll tell you which of the four paths makes the most sense in your case. No data collected, no email asked — everything runs in your browser.

01When does your current VMware contract expire?

In less than 6 months — I'm against the clock Between 6 and 18 months — I have room to decide More than 18 months or no active contract — no urgency

02Where is your platform heading in the next 3 years?

Stay on VMware as long as it makes sense — no forced migration General-purpose open source (Proxmox, OpenStack) Containers and Kubernetes (OpenShift, cloud-native)

03How "VMware-heavy" is your stack today?

We use vSAN, NSX and/or Aria in production Pure vSphere: VMs on external storage Mixed — some clusters with vSAN, some without

Answer all 3 to see the result

Your initial recommendation

04 · Path 2 in detail

What is third-party support for VMware?

It's not "tech support" in the usual sense. It's what happens when the vendor stops being your maintenance provider and someone else steps in to do that work — us, in this case. We keep your vSphere 7 or 8 stable, patched and under contractual SLA while you decide what to do long-term. It does not replace vendor version upgrades. It does replace the maintenance contract — which is where the money goes.

Customers hire us for four reasons, in varying order:

Staying on vSphere 7 or 8 for another five to ten years without anyone pushing you to upgrade. If your platform is stable, you don't need a new version — you need yours to stay secure.
Getting the lever back: you set the timeline, not Broadcom's End of General Support date.
Pulling money out of software maintenance and putting it where it adds value — new hardware, a project you've been putting off for a year, one more person on the team.
A single contract for the entire stack (hypervisor, hardware, guest OS). You stop collecting vertical contracts with whichever vendor.

It fits especially well when your vSphere is solid and you want to stretch it while evaluating Proxmox or OpenShift calmly — or neither, if you change your mind on the way. We cover vSphere 7 and 8 from Spain, in English (and Spanish, and French), with an assigned engineer who doesn't rotate. Scope, SLA and process: third-party VMware support. Same approach for SAP lives at the third-party support hub.

05 · Paths 3 and 4 in detail

And if I want to migrate? Proxmox or OpenShift?

It depends on where your platform is heading over the next five years.

Proxmox VE — the lateral migration

Proxmox VE is the natural answer if what you have is a classic VMware shop — Windows and Linux VMs, shared storage, backups — and you want an open source hypervisor that resembles what you already operate. It supports VM import from VMware, runs on KVM and LXC, and offers enterprise support subscriptions. It's a lateral migration, not a paradigm shift.

OpenShift Virtualization — Kubernetes consolidation

OpenShift Virtualization (based on KubeVirt) is the answer if your organization is already heading toward containers and you want a single platform for VMs and pods. You can run virtual machines as Kubernetes resources alongside your containerized applications, sharing the same network and storage. There's more learning curve, but also more runway if your roadmap is cloud-native. This is also the area where our GSC data shows the most interest from English-speaking visitors — VMware-to-OpenShift migration has become a real conversation in 2026.

A third path: OpenStack

There's a fourth destination worth keeping in mind: OpenStack with Ceph is still a solid option for large environments that want to operate a complete private cloud. Choosing between the three isn't ideological; it's about technical fit and team capability.

06 · Cost and timing

How much does it cost to migrate from VMware? And how long does it take?

There's no catalog price. Anyone giving you a number without looking at your infrastructure is making it up. What it takes and what it costs depends on three things:

Estate size: number of hosts, number of VMs, TB size, presence of vSAN/NSX.
Network and storage complexity: distributed switches, microsegmentation, replication, DR.
Upper-stack dependencies: backup, monitoring, automation, CI/CD.

As planning reference:

A migration of dozens of VMs from vSphere to Proxmox or OpenShift typically runs in weeks, with controlled per-service windows.
A project on hundreds of VMs runs in months, in waves, using a strangler pattern: new workloads on the destination platform, existing workloads migrated in blocks.

Key insight

What lengthens (and increases the cost of) projects usually isn't the hypervisor — it's the dependencies hanging off it: backup, DR, legacy automation, CMDB integrations. That's why the first deliverable of any serious migration is an inventory and dependency map, not a PoC of the new hypervisor.

07 · Method

What's the recommended order to decide?

This is the procedure we apply at SIXE when a customer asks "what do I do with VMware?". Check the steps off as you complete them — the bar tells you how much you have left and the plan is yours.

SIXE method · 5 steps before renewing or migrating 0 / 5 completed

Real estate inventory

Hosts, cores, VMs, vSAN, NSX, Aria, active contracts and expiration dates. Without this, any calculation is fiction.

Upper-stack dependency map

Backup, DR, monitoring, automation, CMDB integrations. The real timelines — and the hidden risks — live here.

Three comparable numbers

Cost of renewing with Broadcom under the new model · Cost of third-party support for 12-24 months · Estimated migration cost (labour + tooling + training).

Informed decision — or combination

The four paths can be combined. Frequent pattern: third-party support for 18 months + progressive migration to Proxmox for standard workloads and to OpenShift for those heading to containers.

Wave-based execution plan

Quarterly review. The point is to separate the technical decision from the commercial calendar — the lever is in your hand, not in the renewal date.

08 · Team

What about the team's training?

Any of the four paths requires training, though in different proportions:

Stay on VMware under Broadcom: little new training, mostly on the licensing model and bundles.
Third-party support: no additional training; the team keeps operating what they already know.
Proxmox VE: moderate training; the mental model resembles vSphere but tooling and networking differ.
OpenShift Virtualization: significant Kubernetes training; start it before the migration, not during.

We're a training partner for several of these platforms: VMware, Red Hat (including OpenShift), and KVM-based solutions. If you want to keep your team certified on what they already operate, we run official VMware vSphere training. When migration is paired with early training, waves go faster and with fewer incidents.

Four paths for VMware in 2026: continue, third-party support, Proxmox and OpenShift

Four paths for your VMware infrastructure in 2026 — all of them valid; it depends on your stack, your timeline and your budget.

10 · Our position

Is VMware a bad platform after Broadcom?

No. And it's worth saying. Here are things we could say for easy clicks, and won't:

That VMware is a bad product. It isn't — we've supported vSphere for more than fifteen years.
That Broadcom is the villain. It's a legitimate commercial decision by a vendor. Customers have to decide what to do with it, not insult whoever made it.
That Proxmox or OpenShift are "the answer". They're an answer when they fit. In other cases, what fits is staying on VMware — with or without Broadcom.

What we will say

Don't decide in a rush. Do the math with all four. And if you need time to do it right, third-party support exists precisely for that. We've been running VMware since before Broadcom existed. We also run Proxmox, OpenShift and OpenStack. Whatever you decide, we execute — that's the difference.

Summary

The essentials in 5 points

If you skipped here

→ The model changed, not the platform. Subscription (VCF/VVF) instead of new perpetuals. The perpetuals you already own are still yours.

→ Four reasonable paths: stay with Broadcom, third-party support, migrate to Proxmox or move to OpenShift. All four work.

→ Third-party support = buying time without compromising security. Your vSphere 7 or 8 stays patched and SLA-covered, but the contract is no longer with Broadcom.

→ Don't start with the new-hypervisor PoC. Start with the inventory and dependency map. The hypervisor is almost never the hard part.

→ The four paths combine. Most frequent pattern: 12-18 months of third-party support + progressive migration in parallel.

FAQ

Frequently asked questions

Is third-party VMware support legal?

Yes — and it's not a grey area. It covers operational maintenance of the versions you already have deployed, without redistributing software or modifying licenses. It does not replace vendor version upgrades — it replaces the maintenance contract, which is something else.

Can I keep using VMware if I don't renew with Broadcom?

If you have prior perpetual licenses, yes: you can keep running them. What you lose is access to new updates and direct vendor support. To cover that gap, there's third-party VMware 7 and 8 support with contractual SLA.

When does support for vSphere 7 and vSphere 8 end?

VMware vSphere 7 reached End of General Support on October 2, 2025, per Broadcom's official communication. vSphere 8 is currently scheduled for 2027. Dates are updated periodically in the official lifecycle portal.

Is Proxmox VE a serious enterprise alternative?

Yes, and anyone still claiming otherwise hasn't looked at Proxmox in years. It runs in production in serious organizations, has enterprise support subscriptions and a mature ecosystem of backup, high availability and clustering. The difference with VMware isn't about technical maturity — it's about model (open source vs. proprietary) and tooling.

Does OpenShift Virtualization replace vSphere?

For many workloads, yes. It runs VMs as Kubernetes objects and lets you consolidate VMs and containers on a single platform. If your organization isn't moving toward Kubernetes in the next few years, it's not for you. If you already are, it's one of the strongest cards on the table.

How much will I exactly save by migrating or moving to third-party support?

It depends on your estate and current model. Significant savings are common in large infrastructures with bundles that aren't used at 100% — but you can only state a number after running the math with your numbers. Any percentage without your inventory is marketing.

Same approach for SAP?

Yes. We apply the same "you decide, we execute" logic to SAP infrastructure — IBM Power, AIX, Linux for SAP HANA. It lives at third-party SAP support.

Second opinion, no fluff

Want to see the four paths with your numbers, not ours?

We'll put together a short report with the real cost of each option applied to your actual inventory: stay with Broadcom, third-party support, Proxmox or OpenShift. First conversation is free — if we don't fit, we don't fit. If we do, you'll tell us.

Request an assessment +34 91 198 02 43

How to Upgrade Debian 12 to Debian 13 Trixie (2026 guide)

May 27, 2026/in News

Linux · Debian · Systems

How to upgrade Debian 12 to Debian 13 Trixie without breaking production.

Debian 13 "Trixie" is now the stable release. This is the step-by-step method we use at SIXE to upgrade production servers: preparation, repositories, full-upgrade and a tested rollback plan. No surprises.

8 min read●Technical guide●May 2026

To upgrade from Debian 12 Bookworm to Debian 13 Trixie: back up, fully patch Bookworm, point the repositories from bookworm to trixie, run apt upgrade --without-new-pkgs first and then apt full-upgrade, clean up and reboot.

Simple on a lab box. A different story across a production fleet with databases, critical services and SLAs. At SIXE we have spent more than 15 years keeping Linux infrastructure running in production, and this is the exact methodology we use to run a dist-upgrade without unplanned downtime. Only the 12 → 13 jump is supported: if you are on Debian 11, move to Debian 12 first.

2030

Trixie support
(3 yrs + 2 LTS)

~59,000

Packages in
the repositories

20-60'

Typical upgrade
duration

01 · What's new

What is Debian 13 Trixie and what changed from Bookworm?

Debian 13 "Trixie" has been the stable release of Debian since 9 August 2025. It ships the Linux 6.12 LTS kernel, the completion of the /usr merge (now mandatory), the move to 64-bit time_t (preparing the Year 2038 problem on 32-bit architectures) and APT 3.0, with cleaner output and better dependency resolution.

For a production server it is not a revolution but exactly what you expect from Debian: a cleaner base, a modern kernel and five years of security support ahead. The key operational point is that the support clock resets — and Bookworm's clock is starting to run out.

In context

Trixie does not force you to relearn anything: same APT, same philosophy. The effort is in planning the jump, not adapting to a new system.

02 · Lifecycle

How long is Debian 12 Bookworm supported?

Since Trixie was released in August 2025, Debian 12 became oldstable. It keeps LTS security support until roughly June 2028, but it no longer receives full support from the security team. It is not a critical emergency, but every month you wait adds technical debt and shrinks the window to upgrade calmly.

Support windows for Debian 12 and Debian 13 — approximate dates per the Debian lifecycle

Recommendation

Do not wait until the end of Bookworm's cycle. Plan the upgrade in a quiet window, not against the clock when security patches stop arriving.

03 · Preparation

What should you prepare before upgrading?

A dist-upgrade is safe if you prepare it. Most disasters we have seen come not from the upgrade itself but from skipping this phase. Tick every item before you start:

Pre-flight checklist0 / 6 done

✓Full backup or snapshot. On a VM, take a full snapshot: it is your rollback button.

✓Read the Debian 13 release notes for your case (known issues).

✓Enough disk space in / and /var to download the new packages.

✓Out-of-band access (console / IPMI / KVM) in case SSH drops during the process.

✓Clean up /boot of old kernels so the 6.12 kernel fits.

✓Maintenance window agreed and users notified.

All six ticked? Then yes, go ahead with the upgrade.

04 · Step by step

How to upgrade Debian 12 to Debian 13 step by step

The process has six phases: bring Bookworm up to date, point repositories to trixie, disable third-party repos, run the minimal upgrade first and then the full one, clean up and reboot with verification. Here is the flow and the exact commands.

The upgrade in 6 phases

Patch BookwormStart from a 100% up-to-date system

Repos to Trixiebookworm → trixie (incl. trixie-security)

Disable third-party reposRe-enable them one by one afterwards

Minimal + full upgrade--without-new-pkgs then full-upgrade

Clean upautoremove + autoclean

Reboot & verifycat /etc/debian_version → 13.x

1. Bring Debian 12 fully up to date

Any pending patch turns into a conflict during the jump. Start from a pristine Bookworm:

root@debian12 — bash

$ sudo apt update
$ sudo apt upgrade
$ sudo apt full-upgrade
$ sudo apt --purge autoremove

2. Point the repositories to Trixie

Replace bookworm with trixie in your APT sources. This also covers bookworm-security → trixie-security. Review the result with cat before continuing.

edit APT sources

# Classic format
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# DEB822 format (recent Debian 12 installs)
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources

3. Temporarily disable third-party repositories

Any external repo in /etc/apt/sources.list.d/ (Docker, PostgreSQL, etc.) can block the upgrade if it does not support Trixie yet. Disable them now and re-enable them one by one afterwards, checking that each already publishes for Debian 13.

4. Run the upgrade: minimal first, full second

The minimal upgrade reduces the risk of dependency conflicts. Monitor the process: you will answer a few prompts about modified configuration files.

root@debian12 — dist-upgrade

$ sudo apt update
$ sudo apt upgrade --without-new-pkgs   # minimal upgrade
$ sudo apt full-upgrade                 # full upgrade

5. Clean up obsolete packages

clean up

$ sudo apt --purge autoremove -y
$ sudo apt autoclean

6. Reboot and verify

root@debian13 — verification

$ sudo reboot
# after reboot:
$ cat /etc/debian_version   # -> 13.x
$ uname -r                  # -> 6.12.x
$ systemctl --failed        # no failed services

05 · Rollback

How long does it take and can you roll back?

On a typical server the upgrade takes 20 to 60 minutes depending on the number of packages and disk and network speed. Rolling back a dist-upgrade is not trivial once the packages are installed: that is why the prior snapshot is non-negotiable. On VMs, reverting to the snapshot takes minutes; on physical hardware, the rollback plan is restoring from backup.

Golden rule

Never do a major version jump in production without a tested way back. A backup you have never restored is not a backup: it is a hope.

06 · Common errors

What are the most common errors upgrading to Trixie?

What we see most in production, and how to avoid it:

Third-party repos without a Trixie release blocking apt: disable them first (step 3).
Full /boot preventing the new kernel from installing: clean old kernels before you start.
Configuration files overwritten by accepting the package version blindly: when in doubt, keep yours and review afterwards.
Forgetting --without-new-pkgs in the minimal phase, which triggers dependency conflicts.
Custom services assuming non-merged /usr paths: the /usr merge is now mandatory in Trixie.

07 · In context

Debian or Ubuntu for your server?

The question we get most often. There is no universal answer: it depends on whether you value control and independence (Debian) or integrated commercial support and tools like Ubuntu Pro and Landscape (Ubuntu). Here is the quick comparison:

Debian 13Ubuntu ProRHEL

Governance

Community

Canonical

IBM / Red Hat

Support / release

5 yrs + ELTS

10 yrs

Packages

~59,000

~30,000

~5,000

Licence cost

€0

Per node

Local-language support

SIXE

SIXE UP

SIXE

Running Ubuntu? As a Canonical partner we have you covered too with SIXE UP. And if your case is moving between distributions, we handle migrations with no downtime.

Upgrading Debian 12 Bookworm to Debian 13 Trixie on production infrastructure

08 · Professional support

What if you'd rather not touch production yourself?

Upgrading a lab box is an afternoon. Upgrading a production fleet with SLAs, databases and critical services is another story: you have to inventory dependencies, validate in staging, coordinate windows and have a tested rollback.

That is exactly what we do at SIXE. We offer professional Debian support — planned version upgrades, hardening with Wazuh monitoring, and incident resolution with SLA — and, when it is urgent, 24/7 support. Want your team trained? We run official Linux training.

15+ years keeping Linux in production

Senior engineers who speak your language, no helpdesks, no escalations. Need to upgrade several servers to Debian 13? Tell us about your case and we will propose a plan with a maintenance window and rollback.

Summary

The essentials in 5 points

For the busy reader

→ Debian 13 Trixie is the stable release since August 2025; Debian 12 is now oldstable (LTS until ~2028).

→ Back up / snapshot before anything else. It is your only real rollback.

→ Start from a 100% patched Bookworm, switch repos to trixie and run upgrade --without-new-pkgs before the full-upgrade.

→ Disable third-party repos during the process.

→ Only 12 → 13 is supported: from Debian 11, go through Debian 12 first.

FAQ

Frequently asked questions

Can you upgrade from Debian 11 directly to Debian 13?

No. Debian only supports upgrades between consecutive releases. From Debian 11 "Bullseye" you must first upgrade to Debian 12 "Bookworm" and, once there, to Debian 13 "Trixie".

Do I lose my data and configuration when upgrading?

No, a dist-upgrade preserves data and configuration. Even so, a full backup or snapshot is mandatory: it is your rollback plan if anything fails.

Is it better to upgrade or reinstall from scratch?

For a well-maintained server, the dist-upgrade is safe and much faster. A clean reinstall only pays off if the system carries a lot of technical debt or inconsistent configuration.

Sources

References

Debian. Debian 13 "trixie" Release Information. debian.org/releases/trixie

Debian. Debian 13 Release Notes. debian.org/releases/trixie/releasenotes

Debian. Debian 13 "trixie" released (2025-08-09). debian.org/News/2025

Debian Security Team. debian.org/security

Written by the SIXE systems engineering team. Last updated: May 2026.

Professional Debian support

Need to upgrade your servers to Debian 13?

We propose an upgrade plan with a prior audit, staging validation, a maintenance window and a tested rollback. Senior engineering, with SLA.

Contact SIXE +34 91 198 02 43

NIS2 compliance with Wazuh

May 21, 2026/in News

Cybersecurity · NIS2 · Wazuh

NIS2 compliance with Wazuh.

The NIS2 directive requires monitoring, incident handling and risk management capabilities that most organisations don't yet have in place. Wazuh is a free, open source platform that covers a large part of what the directive demands — but not all of it. This guide explains what it does, what it doesn't, and what you actually need to pass an audit.

12 min read●Cybersecurity · Compliance●May 2026

NIS2 (Directive EU 2022/2555) is the EU regulation that raises cybersecurity standards for businesses operating in critical and important sectors. If your organisation provides essential services — or supplies technology to one that does — this applies to you. The fines are real: up to €10 million or 2% of global turnover.

Wazuh is an open source security platform that centralises your logs, detects threats, monitors vulnerabilities and generates the evidence trail an auditor expects. It's free, widely adopted across European public administrations and research institutions — including CERN — and at SIXE we deploy it in production environments configured specifically for regulatory compliance. This article explains NIS2's requirements in plain language, maps them to Wazuh's capabilities, and is honest about the gaps.

€0

Wazuh licence cost

NIS2 measures supported

24h

Incident early warning

3K+

Pre-built rules

01 · Scope

Does NIS2 apply to your organisation?

NIS2 broadens the scope of the original 2016 directive significantly. It applies to essential entities (energy, transport, banking, health, water, digital infrastructure, public administration) and important entities (postal services, waste management, food, manufacturing, chemicals, digital providers). If you supply technology or services to any of these sectors, you may also fall within scope.

Tap each card to find out if NIS2 applies to you

"We're a managed service provider hosting infrastructure for a hospital group."

Tap to reveal

Yes, it applies Healthcare is an essential sector under NIS2. As a technology supplier to that sector, you fall within scope through the supply chain provisions (Article 21.2.d).

"We're a mid-size manufacturing company with 300 employees."

Tap to reveal

Yes, it applies Manufacturing is classified as an "important" sector under NIS2. Medium and large enterprises in this sector are in scope. Supervision is reactive (post-incident), but the obligations are real.

"We're a 15-person marketing agency with no public-sector clients."

Tap to reveal

Probably not Small enterprises outside the listed sectors are generally not in scope. But if you handle data for clients in essential sectors, check whether your contracts include NIS2 supply chain requirements.

"We operate a cloud platform used by several EU public administrations."

Tap to reveal

Yes, it applies Digital infrastructure providers (cloud, DNS, data centres) are classified as essential entities under NIS2. Proactive supervision applies, and the obligations are the most stringent.

"We're an energy company distributing electricity across three EU countries."

Tap to reveal

Yes, essential entity Energy is a core essential sector. You face proactive supervision, mandatory incident reporting (24h/72h/1 month), and penalties up to €10M or 2% of global turnover.

Essential vs. Important: two levels of obligation

Essential entities (energy, health, transport, digital infrastructure, banking, public administration) face proactive supervision — authorities can audit you at any time. Important entities (manufacturing, food, chemicals, postal, digital providers) face reactive supervision — authorities investigate after an incident or a complaint. The security obligations under Article 21 are the same for both. The difference is how strictly they're enforced.

02 · What it requires

NIS2 describes SIEM capabilities — without using the word

A SIEM (Security Information and Event Management) is a system that collects log data from all your servers and devices, analyses it automatically to find suspicious patterns, and raises alerts when something looks wrong. Think of it as a security camera for your entire IT infrastructure — one that can actually understand what it sees.

NIS2 doesn't say "install a SIEM". But Article 21 requires a set of measures that in practice demand SIEM-class capabilities:

Incident handling (Art. 21.2.b) — detect, respond to and report security incidents. NIS2 requires a three-stage reporting timeline: early warning within 24 hours, notification within 72 hours, and a final report within one month.
Risk management (Art. 21.2.a) — continuous risk analysis and policies for information system security.
Business continuity (Art. 21.2.c) — backup management, disaster recovery, crisis management.
Supply chain security (Art. 21.2.d) — security of relationships with direct suppliers and service providers.
Vulnerability handling (Art. 21.2.e) — vulnerability disclosure and management.
Monitoring and logging (Art. 21.2.g/h) — policies for assessing the effectiveness of cybersecurity measures, including logging and monitoring of network and information systems.

Meeting the 24-hour early warning requirement without automated detection is extremely difficult. Detecting incidents, preserving evidence, and reporting within the required timelines is exactly what a SIEM does.

Key takeaway

NIS2 doesn't mandate a specific tool. It prescribes outcomes — incident detection, response, logging, risk management. Using Wazuh to deliver those outcomes is a technical and economic decision, not a regulatory requirement.

Where ISO 27001 fits in

ISO 27001:2022 is a voluntary international standard for information security management. Many organisations pursue it alongside NIS2 because the controls overlap significantly. Annex A controls A.8.15 (Logging), A.8.16 (Monitoring activities), A.8.8 (Vulnerability management) and A.8.7 (Malware protection) map directly to Wazuh capabilities. If you're building for NIS2 with Wazuh, you're covering much of ISO 27001's technical layer at the same time.

03 · What Wazuh covers

Which NIS2 and ISO 27001 measures does Wazuh support?

Wazuh is an open source platform (free) that combines several security functions in a single product: it centralises logs from all your devices, watches for changes in critical files, detects known vulnerabilities, checks that your servers follow security best practices, and can automatically block an IP that's trying to brute-force its way in.

It doesn't cover everything NIS2 or ISO 27001 requires — no product does on its own. But it supports the technical measures that require monitoring, detection and traceability:

NIS2 / ISO 27001 requirement Wazuh capability What it does, in plain terms

Incident detection (Art. 21.2.b)

Real-time log analysis

Collects and correlates events across all endpoints to spot threats

Incident response (Art. 21.2.b)

Active Response

Blocks IPs, isolates hosts, kills processes automatically on alert

Vulnerability handling (Art. 21.2.e)

Vulnerability Detection

Scans installed packages against CVE databases to find what needs patching

Logging (A.8.15)

Centralised log management

Collects, normalises and archives logs from every monitored system

Monitoring (A.8.16)

Continuous monitoring

24/7 monitoring of all agents with dashboards and alert rules

Malware protection (A.8.7)

FIM + YARA + VirusTotal

File integrity monitoring, signature scanning, malware detection

Configuration management (A.8.9)

Security Configuration Assessment

Checks your servers against CIS Benchmarks and flags deviations

Access control monitoring

Authentication rules

Detects brute force attempts, failed logins and suspicious access patterns

Intrusion detection (Art. 21.2.a)

Suricata + MITRE ATT&CK

Network IDS with custom rules mapped to known attack techniques

Effectiveness assessment (Art. 21.2.g)

Dashboards + reporting

Real-time compliance and operational metrics for auditors and management

Drag the slider — how does enforcement differ?

Important entity Essential entity

Art. 21All security measures (same for both)✓

Art. 23Incident reporting (24h / 72h / 1mo)✓

Art. 32Proactive supervision by authorities—

Art. 34Fines up to €10M or 2% of turnover—

Art. 32.5Management personal liability—

ScopeRandom audits, on-site inspections—

Important entity — Same security obligations as essential entities, but reactive supervision (authorities investigate after incidents). Fines up to €7M or 1.4% of turnover.

An important nuance: the table above shows Wazuh's technical capabilities. But a tool doesn't "comply" with NIS2 — your organisation does. Wazuh is the instrument; policies, procedures, governance and an incident response plan are the framework that gives it legal validity.

04 · What it doesn't cover

What Wazuh does NOT do on its own

This is the section most vendors skip. It's also the one that builds the most credibility.

Wazuh does not replace

A risk management framework. NIS2 requires a formal, ongoing risk analysis process. Wazuh detects threats, but it doesn't assess business risks or define risk appetite.

Governance and policies. You need documented security policies approved by management. NIS2 Article 20 makes management directly accountable. No tool writes these for you.

Incident reporting. Wazuh detects incidents and preserves evidence. But filing the 24h early warning, 72h notification and final report with your national authority is an organisational process, not a software feature.

Supply chain security. Article 21.2.d requires you to manage risks in your supply chain. Wazuh monitors your own infrastructure, not your suppliers'.

Business continuity planning. Backup strategy, disaster recovery, crisis management — these are organisational capabilities. Wazuh can monitor backup integrity, but it doesn't design your DR plan.

A team that reviews alerts. A SIEM that nobody looks at is a security camera with the monitor turned off. Wazuh generates alerts; if nobody triages and acts on them, compliance is only on paper.

Understanding these boundaries doesn't weaken the case for Wazuh — it strengthens it. When you know what it does and what it doesn't, you can build a realistic project instead of one that falls apart at the first audit.

05 · No product certification

NIS2 doesn't certify products — it demands outcomes

Unlike some national frameworks that maintain catalogues of "approved" security products, NIS2 doesn't prescribe specific tools. There is no "NIS2-certified SIEM" label. The directive requires organisations to implement appropriate technical and organisational measures proportionate to the risks they face.

This means two things:

You can use Wazuh. There's no regulatory barrier to using open source tools for NIS2 compliance. What matters is demonstrating that your measures are effective, documented and proportionate.
You need to prove it works. During supervision or audit, you'll need to show evidence that your monitoring, detection and response capabilities actually function — through logs, dashboards, incident records and documented procedures.

This is where Wazuh's audit trail and reporting capabilities become valuable: they generate the evidence an auditor needs to see. But the evidence only has value if it's organised, retained and linked to your documented risk management process.

Key for audit readiness

Any Wazuh deployment for NIS2 needs documented procedures that link the tool's outputs to your risk management framework. Detection without documentation is invisible to an auditor.

06 · Migrating from commercial SIEM

Switching from Splunk or QRadar without losing compliance

If you're running a commercial SIEM with a renewal coming up, Wazuh is a viable alternative. The question isn't whether it works — it's how to migrate without creating a gap in your compliance evidence.

From commercial SIEM to Wazuh — without a compliance gap

Audit active rulesWhich rules does someone actually look at? Not the default ones nobody touched in five years.

Translate rules to WazuhRewrite custom rules in Wazuh format + build decoders for your internal applications.

Export historical dataArchive past events in a neutral format. Without this, auditors see a gap in your records.

Run in parallel for 4–6 weeksBoth SIEMs operating simultaneously. Validate that Wazuh captures everything the old one did.

Validate with your auditorOptional but recommended. Get sign-off before decommissioning the old system.

Decommission + documentDocument the transition in your risk management records. No gap in your compliance trail.

At SIXE we have a strong IBM QRadar practice with official training courses. We know what QRadar does and what Wazuh does, and exactly which pieces need to be rebuilt when you migrate.

07 · The mistake everyone makes

Installing Wazuh out of the box is not NIS2 compliance

Wazuh ships with over 3,000 pre-built detection rules. Most of them don't apply to your environment. If you only run Linux servers but leave Solaris, Windows Server 2012 and AIX rules active, what you get is noise — alerts nobody understands, nobody reads, and after a few weeks, nobody checks.

What the default installation is missing

No NIS2-specific dashboards. The built-in compliance dashboards cover PCI DSS, HIPAA, GDPR and NIST. For NIS2 you need to build them: panels grouped by Article 21 measures with data an auditor can review at a glance.

No decoders for your internal applications. Your internal portals, batch processes and custom software — without decoders tailored to these, their logs arrive as unstructured text and correlation becomes meaningless.

Installation takes 1–2 days. Tuning takes 4–6 weeks. Installation is what looks like the project. Tuning is the project.

If you already have Wazuh deployed but untuned, tell us what you have — the initial assessment has no commitment.

08 · Preparing for audit

What you need ready before supervision or audit

NIS2 supervision can be proactive (essential entities) or reactive (important entities). Either way, when authorities or auditors come knocking, these are the documents and evidence they'll expect:

Risk management documentation — a formal risk analysis linked to the Article 21 measures you've implemented, including which tools support each measure and why.
Log retention policy — how long you keep logs, where they're stored and how integrity is maintained. NIS2 doesn't specify a minimum period, but industry practice is 12–24 months depending on your risk assessment.
Incident response procedures — who receives alerts, how incidents are triaged, contained and reported within the 24h/72h/1-month timeline.
Vulnerability management procedures — how often you scan, how fast you patch, what your SLA is based on severity.
NIS2-specific dashboards — compliance views grouped by Article 21 measures, separate from generic PCI/HIPAA panels.
Archived evidence — periodic exports of critical events, rule configurations and change logs. Ready to hand over without last-minute scrambling.
Continuous improvement records — evidence that you review and update your measures regularly, not just when an audit is announced.

09 · Training

Training your team to operate Wazuh for NIS2

A monitoring platform that nobody reviews doesn't detect incidents — it just records them. If your IT team doesn't understand what they're looking at in the Wazuh dashboard, alerts accumulate unmanaged and the tool becomes invisible.

The skills needed to operate Wazuh in a compliance context are specific: reading events and distinguishing real alerts from noise, building custom rules for your applications, mapping evidence to NIS2 and ISO 27001 requirements, and responding to incidents within the reporting timelines.

Wazuh training →

Summary

The essentials, for those short on time

In 6 points

→ NIS2 describes SIEM capabilities in Article 21 — incident handling, monitoring, logging, vulnerability management. It doesn't name a tool.

→ Wazuh supports 10 NIS2 and ISO 27001 measures related to monitoring, detection and traceability.

→ There is no NIS2 product certification. The directive prescribes outcomes, not tools. You demonstrate compliance through documentation and evidence.

→ Wazuh doesn't replace risk management, governance, incident reporting processes, supply chain security or the team that reviews alerts.

→ Installing is not complying. The gap between "we have Wazuh" and "we're audit-ready" is 4–6 weeks of serious tuning work.

→ Wazuh is free. Implementing it properly is not.

FAQ

Frequently asked questions

Does NIS2 require a SIEM?

Not by name. But Article 21 requires incident handling, continuous monitoring and logging capabilities that in practice are only achievable with a SIEM or equivalent platform. Wazuh provides most of these capabilities natively.

Can Wazuh help with NIS2 compliance?

Wazuh provides the technical capabilities to support several Article 21 measures — monitoring, detection, vulnerability management, incident response and audit logging. But compliance is demonstrated by the organisation through policies, procedures and governance, not by any single tool.

Is Wazuh certified for NIS2?

There is no NIS2 product certification scheme. NIS2 prescribes outcomes, not specific tools. Organisations choose their own tooling and demonstrate compliance through audits and supervision by national authorities.

Does Wazuh support ISO 27001?

Yes. Wazuh maps to several Annex A controls in ISO 27001:2022 — particularly A.8.15 (Logging), A.8.16 (Monitoring), A.8.8 (Vulnerability management) and A.8.7 (Malware protection). It provides technical evidence that auditors can review during certification.

What's the difference between NIS2 and ISO 27001?

NIS2 is an EU regulation — mandatory for essential and important entities, with fines up to 2% of global turnover. ISO 27001 is a voluntary international standard. Many organisations pursue both: NIS2 for legal compliance, ISO 27001 for the management framework. The technical controls overlap significantly.

How quickly must incidents be reported under NIS2?

Three stages: early warning within 24 hours, incident notification within 72 hours, final report within one month. Wazuh provides the detection and logging to meet these timelines, but the reporting itself is an organisational process.

Sources

References and regulation cited

Directive (EU) 2022/2555 (NIS2). EUR-Lex — Official Journal

Wazuh — Ensuring NIS2 compliance with Wazuh. wazuh.com

Wazuh — Regulatory compliance use cases. wazuh.com

ISO/IEC 27001:2022 — Information security management systems. iso.org

ENISA — NIS2 Directive guidance. enisa.europa.eu

Wazuh — Official documentation. documentation.wazuh.com

Full training catalogue · SIXE.

Last updated: May 2026

Wazuh + NIS2

Let's talk about your project

Tell us which NIS2 category applies to you, what you have in place today and when your next audit is expected. We'll leave with an architecture sketch and next steps.

Book a technical session Wazuh training

Chain of Thought: Why Your AI Model Does Not Reason

May 13, 2026/in News

AI · Reasoning · LLM

Chain of Thought: Why Your AI Model Doesn't Reason.

Chain of Thought is not thinking. It is the statistical shape of thinking. Apple, Arizona State and UC Berkeley prove it with data. Here is what it means for anyone deploying AI in production.

9 min read●AI · Production · Infrastructure●May 2026

Chain of Thought (CoT) is a technique that makes language models generate intermediate steps before answering. While it improves benchmark results, recent research demonstrates it does not constitute genuine reasoning: it is a statistical constraint that mimics the form of human thought.

For organisations deploying AI in production environments, understanding this difference is not a philosophical debate. It is an architectural decision that affects reliability, cost and operational risk. At SIXE we have spent over 15 years designing critical infrastructure where failure tolerance is zero. That experience has taught us a rule that applies equally to an IBM Power cluster and to an AI agent: never trust a single component for anything that cannot go down.

01 · What it is

What is Chain of Thought and why does it look like reasoning?

When you enable "reasoning" or "thinking" mode in models like GPT-5, Claude or DeepSeek, the model generates an intermediate monologue before answering: "okay, first I'll analyse X... now let me consider Y... wait, let me check Z...". In the technical literature this is known as Chain of Thought (CoT).

The problem is that this is not thinking. It is generating text with the statistical shape of human reasoning. The model saw millions of examples of step-by-step reasoning during training and learned to reproduce that pattern. When you ask it to "think", what it actually does is recognise the problem category and fill in the statistical template that best matches.

A concrete example: if you ask a "reasoning" model to size a Ceph storage cluster with 12 OSDs, 3x replication and tolerance for 2 simultaneous node failures, it will return four flawless paragraphs with formulas, failure-domain considerations and a final number. It looks like structured thinking. What it actually did was detect "Ceph sizing problem" and apply the statistical pattern it has seen in hundreds of similar technical documents.

Why does it work? Because most of the time it gets the right answer. The question is what happens when the problem goes off-script.

02 · The evidence

Do LLMs actually reason? What the papers say

CoT works. It measurably improves benchmarks. The relevant question is not whether it works, but why it works. And the answer from the most rigorous studies is uncomfortable.

CoT as a statistical crutch

A team from Arizona State University demonstrated that CoT shines when the problem data falls within the training distribution. As soon as the problem moves outside known territory, performance collapses. It is the difference between a system that has memorised solutions and one that genuinely understands the underlying principles.

CoT as an architectural constraint

CoT is not abstract reasoning: it is a constraint that forces the model to imitate the form of reasoning. Forcing the model to write "first... second... therefore..." makes each generated token influence the next one more coherently. It is an architectural trick that improves the internal coherence of the text, not a cognitive act. The paper Chain-of-Thought Reasoning In The Wild Is Not Always Faithful documents how CoT can give an inaccurate picture of the actual process the model follows to reach its conclusions.

Technical conclusion

CoT is useful for many tasks. But it is not reasoning. It is formal coherence with the appearance of logic.

03 · The decorative

What are "decorative thinking steps" in AI reasoning?

A paper from October 2025 by researchers at UC Berkeley and UC Davis introduced the concept of decorative thinking steps, and their finding is especially relevant for anyone evaluating AI models for production.

The researchers found that many intermediate CoT steps are literally decorative. The model writes things like "wait, let me check... I think I made a mistake... let me recalculate", and then completely ignores that self-correction and delivers the answer it had already decided internally.

The demonstration was elegant: they deliberately perturbed the intermediate steps (changed numbers, altered logic) and checked whether the final answer changed. In many cases, it did not. The conclusion was already decided. The chain of thought was generated afterwards, as post-hoc rationalisation.

Tap each step to discover if it is real or decorative

"Hmm, wait. I think I got the replication factor wrong. Let me recalculate from the beginning..."

Tap to reveal

Decorative The model already had the answer. The "self-correction" did not change the final result. It is narrative theatre.

"Raw capacity = 12 × 8 TB = 96 TB. With 3x replication: 96 / 3 = 32 TB usable."

Tap to reveal

Real This step contains the calculation that determines the final answer. High TTS: the output depends on it.

"Let me verify my answer step by step to make sure I haven't made any calculation errors in the previous estimate..."

Tap to reveal

Decorative Pure rhetorical formula. The model does not re-execute any calculation: it has already emitted the answer tokens. It just adds words that look like rigour.

"Interesting question. Before answering, let me consider multiple angles: the failure domain, OSD balancing and metadata overhead..."

Tap to reveal

Decorative Listing factors without processing them is not analysis. It is the statistical form of what an expert would do. The model has already chosen the answer.

"With 2-node failure tolerance and 4 OSDs per node, the worst case loses 8 OSDs. Minimum guaranteed capacity: (12−8) × 8 / 3 ≈ 10.7 TB."

Tap to reveal

Real Introduces new variables (nodes, OSDs per node) that actually change the result. Without this step, the answer would be different.

A concrete finding: on the AIME dataset, only 2.3% of reasoning steps in the CoT had real causal influence on the model's final prediction. The rest was decoration. (Source: Can Aha Moments Be Fake?, UC Berkeley)

Direct implication

A model explaining well why it reached a conclusion does not mean that conclusion is correct. The explanation is generated alongside (or after) the result, and in many cases it is a justification built on top of a predetermined answer.

04 · Apple

"The Illusion of Thinking": Apple's study that changes everything

If decorative steps demonstrate that CoT does not guarantee reasoning even when it gets the right answer, Apple's study goes one step further: it shows that when the problem gets truly complex, the models give up.

In June 2025, Apple published The Illusion of Thinking, a study that tested state-of-the-art reasoning models on classic computer science puzzles: the Tower of Hanoi, river-crossing problems and other exercises that any first-year student solves with pen and paper.

Model performance with and without CoT by complexity — Based on data from Apple ML Research, "The Illusion of Thinking", June 2025

Drag the slider — how does CoT perform as complexity increases?

Easy Medium Hard

No CoT

88%

With CoT

72%

El modelo sin CoT gana. El "pensamiento" extra solo añade coste y latencia.

The most significant finding is the third one. "Reasoning" models do not just fail on complex problems — they reduce computational effort precisely when they should increase it. It is the equivalent of a monitoring system that stops generating alerts when the infrastructure needs it most.

It is worth noting that the paper sparked debate: a team from CSIC in Madrid replicated part of the experiments and noted that some failures were due to output token limits, not pure cognitive limitations. But the core conclusions — that performance collapses with complexity and CoT does not scale predictably — held up.

05 · Cost

Is it worth paying for reasoning models?

It depends. And that is precisely the answer most vendors do not want to give you.

A case that illustrates the risk: a European company built a "reasoning" agent to classify support tickets. The chain of thought the model generated was narratively flawless. The problem was that 30% of the tickets ended up in the wrong queue, and the model explained with impeccable eloquence why that incorrect classification was the right one. Perfect narrative, wrong result.

This happens because we are confusing quality of explanation with quality of decision. They are different things. A model can produce formally flawless reasoning and reach an incorrect conclusion, exactly the same way a presentation with spectacular charts can defend a wrong strategy.

Rule of thumb

Before paying for reasoning models, benchmark with your real-world use case. Vendor marketing decks show results from their best days. Your data, your edge cases and your specific scenarios determine whether the extra cost is justified.

06 · Perspective

Is AI useless then?

No. And it is important to understand this clearly, because the pendulum can swing to the other extreme just as easily.

An LLM not reasoning like a human does not make it useless. It means you need to understand exactly what it does to use it correctly.

An IBM Power10 system running AIX does not "think" about workloads. It has no intuition. What it has is a high-performance RISC architecture, memory bandwidth that an equivalent x86 cannot match, and mainframe-grade reliability (RAS). If you understand what it does, you use it for what it is worth: critical databases, HPC, AI inference at scale. If you do not understand it, you use it as an expensive x86 server and wonder why it underperforms.

The same applies to LLMs. They are extraordinary language processors. They synthesise, translate, draft, classify and extract text patterns at a speed no human team can match. That is real, it has measurable value, and it is transforming operations across every sector.

What they are not is thinking agents with genuine understanding of the world. And selling the latter when what you have is the former is what is creating an expectations bubble that, sooner or later, will correct itself.

07 · In production

How to use AI in production without falling into the trap

In the world of critical infrastructure — IBM Power, AIX, high-availability clusters — there is a principle that never fails: design with redundancy. You never trust a single component for anything that cannot go down.

1. Do not use the explanation as proof the answer is correct

The model's explanation is generated alongside (or after) the result. It is often a post-hoc rationalisation. If the system makes critical decisions, you need independent verification. No matter how well it explains itself.

2. Benchmark with your real use case before choosing a model

For simple tasks, the cheaper model can outperform the expensive one. For medium tasks, CoT pays off. For highly complex tasks, both fail. The only way to know is to test with your real data, not the vendor's.

3. Design architectures with external verification

If your AI architecture is "ask the model and trust what it says", you do not have an architecture. A serious AI deployment includes cross-validation, business rules as a control layer, alerts when model confidence drops, and humans in the loop for critical decisions.

4. Demand evidence, not promises

The AI market is full of extraordinary claims without proportional evidence. A serious vendor shows you benchmarks on your type of data. A less serious vendor shows you a spectacular demo with prepared data.

08 · Our methodology

How do we evaluate AI models for production environments?

At SIXE we apply the same criteria to AI that we have applied to every critical infrastructure component for over 15 years:

Testing with real client data, not generic datasets or prepared demos.
Performance measurement on edge cases, not just the happy path. Errors do not show up in the median; they show up at the extremes.
Redundant architecture always. AI is one more layer in the system, not the entire system. It is complemented by business rules, cross-validation and human oversight where the decision is critical.
Model selection by use case, not by marketing. A model with CoT can be perfect for complex text analysis and entirely unnecessary (and more expensive) for simple classification.
Infrastructure sized for inference. An AI model is only as good as the infrastructure that supports it. We have verified this first-hand with vLLM on IBM Power and with Ceph as the AI storage backend.

Summary

For executives short on time

The essentials in 6 points

→ Chain of Thought is not thinking: it is the statistical shape of thinking, a constraint that improves the coherence of generated text.

→ Apple demonstrated that reasoning models collapse on complex problems and reduce their effort precisely when they should increase it.

→ Only 2.3% of reasoning steps have causal influence on the model's answer. The rest is decoration.

→ Do not pay for "reasoning" without measuring it on your specific use case with your real data.

→ Never use the model's explanation as proof that the answer is correct.

→ Design with external verification. AI is an extraordinary tool, not an oracle.

Sources

References and cited papers

Apple Machine Learning Research. The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity. June 2025. machinelearning.apple.com

Zhao, C. et al. (Arizona State University). Is Chain-of-Thought Reasoning of LLMs a Mirage? A Data Distribution Lens. August 2025. arxiv.org/abs/2508.01191

Zhao, J. et al. (UC Berkeley, UC Davis). Can Aha Moments Be Fake? Identifying True and Decorative Thinking Steps in Chain-of-Thought. October 2025. arxiv.org/abs/2510.24941

Arcuschin, I. et al. Chain-of-Thought Reasoning In The Wild Is Not Always Faithful. March 2025. arxiv.org/abs/2503.08679

Dellibarda Varela, I. et al. (CSIC, Madrid). Rethinking the Illusion of Thinking. July 2025. arxiv.org/abs/2507.01231

Last updated: May 2026

AI in production

Need to evaluate how to integrate AI into your infrastructure?

At SIXE we design AI architectures with the same philosophy we apply to any critical system: redundancy, external verification and real benchmarks. Tell us about your case.

WhatsApp Contact SIXE +34 91 198 02 43

Why your RAG pipeline serves last month’s data

May 12, 2026/in News

RAG · IBM Fusion CAS

Why your RAG pipeline serves last month's data.

Re-vectorizing thousands of documents every time something changes doesn't scale. IBM Fusion CAS integrates vectorization directly into storage: documents change, vectors update themselves.

7 min read●RAG · Storage · Unstructured data

IBM Fusion CAS (Content Aware Storage) is a capability built into IBM Fusion that vectorizes, indexes, and keeps documents continuously updated directly in the storage layer — without moving data or rebuilding the vector index.

If you have a RAG pipeline in production, you've probably run into this: documents change, but vectors don't. The contract was amended in March, the chatbot still answers with the December version. It's not a model problem — it's that nobody re-ran the ingestion pipeline. CAS solves exactly that.

80–90%

Of enterprise data is
unstructured
Source: IBM Redbooks

40%

AI prototypes never
reach production
Due to data quality

Data copies required
with CAS
Zero-copy ingestion

01 · The problem

Why do vector embeddings in a RAG pipeline go stale?

Between 80% and 90% of enterprise data is unstructured — PDFs, scanned documents, spreadsheets, contracts, support tickets. In a conventional RAG pipeline, the flow to make them accessible to AI is: extract documents → parse → generate embeddings → load into a vector database → search when a query arrives. It works. Until the documents change.

Versioned technical manuals, contracts with addenda, quarterly financial reports, support tickets that get reopened. Every time something changes, you have to re-run the entire pipeline. With thousands of documents, that means hours of GPU time, massive data movement between systems, and a team babysitting the process. According to IBM, 40% of AI prototypes never reach production precisely because of data quality and availability issues.

The usual alternative is to skip re-vectorization. And then your AI answers with two-month-old information.

The security gap nobody sees

In most RAG deployments, vectorization strips out the access controls from original documents. The chatbot has access to the entire vector index, and suddenly a sales rep can extract financial information they shouldn't see because the file's ACLs weren't propagated to the vectors. CAS solves this: vectors inherit the permissions from the source document.

02 · The solution

What is IBM Fusion CAS and what does it do?

CAS (Content Aware Storage) is a capability built into IBM Fusion that operates on top of Storage Scale. It's not a separate product. Storage goes from being a place where bytes are kept to understanding what's inside each file: its structure, its semantics, and how it has changed since it was last processed.

AI-Q Research Assistant architecture with IBM Fusion CAS — ingestion, vectorization, and RAG query flow

AI-Q Research Assistant architecture on IBM Fusion — Source: IBM Community, Sandeep Zende

Capability Traditional RAG pipeline IBM Fusion CAS

Data movement

Copy to external system

Zero-copy in place

Vector updates

Full re-ingestion

Automatic incremental

Change detection

Manual / cron

Real-time

Access control on vectors

Not propagated

ACLs inherited

GPU acceleration

Inference only

From ingestion

Orchestration

Scripts + crons + queues

Built into storage

If you already use Docling (or LibrePower's port for IBM Power) with Milvus and an LLM, you don't need CAS for that to work. A deployment with a few hundred PDFs that rarely change is well served by an orchestrated pipeline and a cron. The tipping point comes when documents number in the tens of thousands, change daily, and access control matters.

03 · How it works

How does CAS process documents without moving them out of storage?

IBM Fusion CAS flow — ingestion and query

📄

Document lands or changes in Storage Scale PDFs, scans, tables, contracts — CAS detects the event automatically

⚡

GPU-accelerated extraction and semantic chunking OCR, table recognition, layout analysis — all in storage, no copies

🧬

Embedding generation with NeMo Retriever Vectorization on NVIDIA Blackwell GPUs — RTX PRO 6000, linear scaling

🗄️

Incremental indexing in integrated vector database Only what changed gets updated — with inherited ACLs from source document

🔁

RAG query: retrieve → reason → refine → respond AI-Q Research Assistant: iterative loop with Nemotron + Llama-3, not a single-shot answer

↻ Continuous loop — data is automatically re-processed when it changes

The key difference from a conventional pipeline: there is no manual step between "the document changed" and "the vector index reflects that change." CAS closes that gap automatically, with NVIDIA Blackwell GPUs accelerating every phase — not just final inference. Ingestion and query throughput scales linearly as more NVIDIA RTX PRO 6000 GPUs are added, as documented in the IBM Redbook on NVIDIA AI Data Platform. On BEIR benchmarks (the industry standard for evaluating semantic search), CAS outperforms the most advanced retrieval systems on the market.

04 · Deployment

On-premises because there is no alternative

The entire architecture runs on-premises. This isn't a preference: if your data falls under GDPR, the EU AI Act, EBA banking regulations, or classified information requirements, sending it to a cloud API for vectorization is not a legal option.

It's the same philosophy we described when talking about building an on-premises AI factory with Ceph and Kubernetes, with one difference: CAS integrates data preparation directly into storage. No separate processing cluster to orchestrate, no message queues between NAS and pipeline, no temporary S3 buckets.

Storage Scale vs Ceph: a new argument

If you're evaluating which storage you need for AI workloads — the decision between Storage Scale and Ceph we covered last week — CAS tips the scale. It's something that only exists in the Storage Scale / Fusion ecosystem and has no direct equivalent in Ceph or any other distributed file system today.

05 · Scope

When does CAS make sense over a hand-built RAG pipeline?

CAS requires IBM Fusion on OpenShift. It's not a component you plug into any infrastructure. If your RAG works fine with Docling + Milvus + a cron job, you don't need this.

It makes sense when several of these conditions apply at once:

High volume of unstructured documents that change frequently.
Granular access control requirements — healthcare, banking, public administration, legal.
Existing or planned IBM infrastructure (Fusion, Storage Scale).
Need for the vector index to stay current without manual intervention.
Data sovereignty and European regulatory compliance.

Technical references

From RAG to Real Research — Sandeep Zende, IBM Community

IBM Redbooks: AI Inference at Scale with Storage Scale ECE and Fusion CAS

Official IBM Fusion CAS documentation

On-premises RAG architecture

Need to size an AI architecture on Fusion?

At SIXE we work with IBM Fusion, Storage Scale, and RAG pipelines in production. Tell us about your use case and we'll help you design the solution.

Contact SIXE +34 91 198 02 43