EDR beyond Windows: protect Linux, AIX & IBM i

/in
Security · EDR / XDR · IBM Power

EDR beyond Windows: protecting Linux, AIX and IBM i.

We map how far today's leading EDR solutions actually reach across your estate — including the servers CrowdStrike and SentinelOne have no agent for. Where the radar reaches, where the blind spots are, and how to close them with open source.

11 min read●Technical analysis●

There's a conversation that comes up every time we review a client's detection strategy. They walk us through their coverage: Windows protected, Linux mostly there, macOS depending on the case. All reasonable. Then we ask: "What about the AIX servers? And the IBM i?" What usually follows is a brief silence.

It isn't an oversight. It's that most EDR solutions on the market — CrowdStrike, SentinelOne, Microsoft Defender — have no agent for AIX or IBM i. And in banking, insurance or logistics, those are precisely the systems running the organisation's most critical transactions.

44%
Of breaches
involve ransomware
0
Leading EDR
agents for AIX
10M+
Annual Wazuh
downloads
24h
Alert deadline
under NIS2
01 · Clearing up the acronyms

EDR, XDR, MDR: three letters that aren't the same thing

The industry stacks up acronyms fast, and the lines between products aren't always clear. Before we go further, it's worth pinning down what each one means — because the difference matters when it's time to protect a server that isn't Windows.

EDR Endpoint Detection & Response Detects threats on endpoints by analysing behaviour, not signatures. It catches the malware that leaves no file behind — exactly what traditional antivirus never sees.
XDR Extended Detection & Response Correlates telemetry from endpoints, network, identity, email and cloud to detect threats from a single platform. It extends visibility beyond the individual endpoint.
MDR Managed Detection & Response Not a technology — a service. Someone runs your EDR/XDR 24/7. It makes sense without an in-house SOC; less so if you already have a team but lack the tooling.
The distinction most people miss

Antivirus looks for known signatures: files that match a malware database. If an attack is new or leaves no file (fileless, living-off-the-land), it won't see it. EDR will — because it doesn't look at files, it looks at behaviour.

02 · The coverage map

How far does your EDR's radar actually reach?

Here's the exercise that rarely happens in a security review: mapping the real EDR coverage of the leading commercial solutions across every kind of system you run in production. Not the datasheet version — the real one.

Windows
x86_64
Full coverage
Linux x86
RHEL · Ubuntu · Debian
Full coverage
macOS
Apple Silicon · Intel
Partial coverage
Linux on Power
ppc64le
Partial coverage
AIX
IBM Power · Unix
Blind spot
IBM i
IBM Power · AS/400
Blind spot
​ Leading commercial EDR covers it ​ Limited or vendor-dependent ​ No agent available

The last two tiles are the problem. CrowdStrike has no agent for AIX or IBM i. Neither does SentinelOne. Neither does Microsoft Defender. It's a blind spot in the commercial EDR market that hits the sectors with the largest regulated attack surface — banking, insurance, healthcare, logistics — which happen to be the ones with the heaviest IBM Power footprint.

The angle few people look at

You're already paying for CrowdStrike, SentinelOne or Microsoft Defender. The problem isn't only a security one — it's that part of your most critical infrastructure sits outside that investment. You're paying for coverage that, by design, never reaches the systems running your transactions.

03 · The market

Consolidation, concentration and a quiet alternative

The EDR landscape has been reshaping itself for a couple of years now. And the most significant move didn't come from the products — it came from the mergers.

The enterprise leader CrowdStrike remains the reference at the high end. The July 2024 incident brought a level of scrutiny that wasn't there before, but technically it's still among the best.
The native integration Microsoft Defender for Endpoint is gaining share on the back of its Microsoft 365 integration. For anyone already in that stack, the marginal cost is hard to beat.
The acquisitions Cisco bought Splunk (USD 28 billion). Palo Alto absorbed the SaaS side of QRadar. The message: detection and response are merging with the SIEM. They're no longer separate products — they're layers of the same platform.
The open-source alternative Meanwhile, Wazuh has passed 10 million annual downloads and added local-LLM threat hunting — with no licensing cost.
04 · Wazuh as EDR/XDR

What works and what doesn't

Let's be specific, because this is a product we work with daily and we know both its strengths and its limits well. Wazuh is open source, lightweight and cross-platform — and, most relevant for this article, its agent runs in IBM i PASE environments and on AIX.

What it does well
  • File integrity monitoring (FIM) and rootkit detection
  • System log analysis and software/hardware inventory
  • CVE-based vulnerability detection and automated active response
  • Agents for Linux, Windows and macOS; deployable on PASE (IBM i) and with an agent for AIX
  • Local-LLM threat hunting since 2025, with no licensing cost
Where its limits are
  • No kernel-level protection like CrowdStrike or SentinelOne
  • No threat sandboxing
  • Functional console, with room to improve on usability
  • The 3,000+ default rules are a starting point, not a turnkey solution
  • Needs a team that knows how to configure and tune it

That last line is the important one. The difference between a Wazuh that generates noise and one that generates actionable intelligence lies in configuration, tuning and knowledge of the environment. For the full comparison with commercial alternatives, it's on our Wazuh page.

05 · Reducing the blind spot

Is there an EDR for IBM i and AIX?

It's the direct question, and the honest answer is: not in the catalogue of the big vendors, but yes — through open source. Back to the two red tiles on the map. If the commercial solutions don't reach AIX and IBM i, three pieces remain that complement each other.

Wazuh on PASE (IBM i) and AIX

Wazuh can be deployed in PASE environments on IBM i, letting you collect system telemetry and events that are then correlated in the central platform. For AIX there's a native agent. They don't match the coverage Wazuh offers on Windows, but they collect system logs, monitor file integrity and detect configuration changes. On IBM i, pairing Wazuh with collection of the QAUDJRN — the native audit journal — adds a layer of visibility most of these systems don't have today.

PowerSC for hardening and compliance

PowerSC is IBM's native tool for AIX and IBM i. It monitors file changes, checks configurations against CIS/STIG standards and generates compliance reports. It isn't an EDR in the strict sense, but it covers the change detection and configuration management that complement Wazuh. IBM itself positions PowerSC as an EDR solution for Power environments.

Open source for IBM Power

Beyond IBM's own tooling, there are open-source repositories maintained specifically for IBM Power that make it easier to deploy monitoring agents and automation tools on AIX and IBM i.

LibrePower: the open-source catalogue for IBM Power It maintains package repositories for AIX and IBM i with the dependencies needed to deploy monitoring agents, audit scripts and automation tools. With AWX and Ansible, you deploy and configure those agents across fleets of Power servers just as you would on Linux. AIX catalogue IBM i catalogue AWX / Ansible
The piece the auditor wants to see

Wazuh + PowerSC + Ansible across IBM Power isn't an off-the-shelf EDR. But it provides visibility over systems the commercial EDR platforms don't cover, and it produces evidence aligned with the monitoring, traceability and detection requirements set out in NIS2.

06 · Where to start

Three steps if you only protect Windows

Audit your real coverage

Inventory every endpoint — not just the ones IT actively manages, but the ones that have been running "on their own" for years. Every AIX server, every IBM i, every production LPAR that sends no telemetry to a central system is a blind spot. If you don't know how many unprotected systems you have, you can't size the solution.

Deploy Wazuh as a baseline

A Wazuh server with agents on everything — Windows, Linux, AIX, IBM i — gives you centralised visibility. It isn't the final step, but it's the one that generates the most insight per euro spent. Our guide to Wazuh and NIS2 walks through the process for environments under regulatory pressure.

Define your response strategy

Detection without the ability to respond is an alarm nobody turns off. Wazuh's active responses (endpoint isolation, IP blocking, process kill) need careful configuration to avoid false positives that hit production. This is where experience matters more than technology.

Where SIXE comes in

Sizing a Wazuh deployment, bringing your Power systems into the EDR strategy, or preparing detection for a NIS2 audit — at SIXE we've spent more than 15 years at that intersection of IBM Power infrastructure and security.

In short

The essentials in five points

What to take away

→ Traditional antivirus isn't enough: it detects signatures, not behaviour. EDR does see fileless malware.

→ The leading EDR solutions have no agent for AIX or IBM i — a blind spot in banking, insurance and logistics.

→ Wazuh is a genuine open-source alternative, with an agent for PASE (IBM i) and AIX, and over 10M annual downloads.

→ Wazuh + PowerSC + Ansible significantly reduces that blind spot and produces evidence aligned with NIS2.

→ The LibrePower open-source ecosystem makes deploying agents and automation on IBM Power simpler.

FAQ

Frequently asked questions

What's the difference between EDR, XDR and antivirus?

Antivirus looks for known malware signatures in files. EDR analyses system behaviour (processes, connections, changes) to detect threats that leave no file behind, such as fileless malware. XDR extends that visibility beyond the endpoint, correlating data from network, email, cloud and identity into a single platform.

Do CrowdStrike or SentinelOne have an agent for AIX or IBM i?

No. The leading commercial EDR solutions have no agent for AIX or IBM i. It's a blind spot that affects sectors with heavy IBM Power footprints: banking, insurance, healthcare and logistics.

Is there an EDR alternative to CrowdStrike or SentinelOne on AIX?

Since CrowdStrike and SentinelOne offer no agent for AIX, the practical alternative combines Wazuh (detection and event collection), PowerSC (IBM's native hardening and compliance) and Ansible for automated deployment. It's not a one-to-one replacement, but it provides the detection layer those platforms don't offer on AIX.

Does this help with NIS2 compliance?

Combining Wazuh, PowerSC and Ansible automation across IBM Power provides a detection and traceability layer over systems that commercial EDR platforms don't cover. Collecting IBM i's QAUDJRN and AIX syslog into a central SIEM produces evidence aligned with the monitoring, traceability and detection requirements set out in NIS2.

Endpoint security · IBM Power

Got blind spots in your EDR coverage?

Tell us which systems are unprotected, how many endpoints you run and which regulations apply to you. We'll get back to you within 24 hours with an outline architecture and a realistic sense of effort. If Wazuh fits, we'll say so. If it doesn't, we'll say that too.

See the Wazuh solution Contact
db2 formacion oficial sixe ibm

Your team is doing manually what Db2 12 already handles

/in
Databases · IBM Db2 · Operations

Your team is doing manually what Db2 12 already handles. And they don't know it.

Backups that take longer than they should, failovers built on a product IBM no longer develops for Linux, downtime for operations the engine now handles online. If your team hasn't updated to Db2 12, they're doing more work than they need to — and possibly taking on risks they no longer have to.

9 min read●Technical analysis●

IBM released Db2 12.1.5 on 9 June 2026 — the sixth mod pack since version 12 shipped in November 2024. With each one, the gap between how a DBA operates and what the engine already does on its own has kept growing. And nobody told the team.

It's not a competence problem. The product has changed underneath and nobody has brought the team up to speed. Version 11.5 has had no new features for years, and between it and 12.1 the engine handles high availability, backups, maintenance and even the types of data it can store in fundamentally different ways. But nobody told the team.

Five concrete situations where it shows. These aren't edge cases — they're the daily reality of a DBA who doesn't know their Db2 already handles what they've been doing by hand for years.

01

The failover your team builds on a product IBM no longer extends

This is the clearest case. Your team configures HADR for high availability. On Linux, they set up TSAMP (Tivoli System Automation) because that's what they learned. It works. But IBM is focusing its new HADR automation on Pacemaker and positions it as the strategic option for new Linux deployments. The reference cluster manager is now Pacemaker, open source, standard, simpler to operate.

What your team doesConfigures TSAMP as the cluster manager for HADR. Follows the documentation they know. Manages failover with Tivoli tooling.
What Db2 12 expectsPacemaker integrated. Native failover automation, decoupled VIP and Overlay IP. In 12.1.5 (June 2026): quorum disk tiebreaker and quorum node fencing.
⚠The cost: an HA layer built on the option IBM no longer extends. It works today, but every mod pack adds Pacemaker automation your team isn't using — and the gap with the official documentation widens.

On AIX, the story points in the same direction with a different actor: the right option for demanding, mission-critical workloads is PowerHA SystemMirror, not TSAMP. PowerHA is the product IBM maintains and evolves for Db2 high availability on Power — more robust, more integrated and better suited to production environments. TSAMP is the layer to avoid, regardless of platform. The conclusion isn't that Linux is the modern option and AIX the legacy one — it's that on both platforms there is a correct option, and TSAMP isn't either of them.

02

The backup window that no longer needs to be this wide

Before version 12, backups processed each tablespace with a single thread. On large databases, backup windows stretched and the DBA accepted them as inevitable. In Db2 12, the behaviour has changed on two specific fronts:

What your team doesAccepts that each tablespace is processed with a single thread. Schedules wide windows. Assumes that history file maintenance happens during the backup and blocks.
What Db2 12 does on its ownMulti-threaded backups — multiple threads processing a single tablespace, with no extra configuration. In 12.1.4 (March 2026): history file maintenance runs asynchronously, without blocking. In 12.1.5 (June 2026): automatic archive log pruning.
⚠The cost: maintenance windows wider than necessary. Every extra hour is operational risk and business coordination that could be avoided.
03

The maintenance that takes the service down to change a column

Changing the scale of a DECIMAL or widening a SMALLINT to INT on a columnar (BLU) table meant recreating the table, migrating data and verifying. In practice, scheduled downtime. In Db2 12.1.4 (March 2026) and 12.1.5 (June 2026), several of these operations no longer require an outage.

What your team doesCreates a new table, migrates data, renames, verifies. Schedules downtime. Same for index reorganisation.
What Db2 12 does on its ownOnline ALTER on columnar tables: alter DECIMAL, widen SMALLINT to INT, DROP and RENAME with no downtime. Online index reorg in 12.1.5 (June 2026). Table movement without service interruption.
⚠The cost: service outages for operations Db2 12 handles online. Every avoidable outage is availability recovered.
04

The architecture your team ruled out with 2022 criteria

This case breaks the pattern of the previous ones, but it's just as relevant: it isn't something Db2 12 does on its own, it's an architecture that is now viable and wasn't before. If anyone on your team evaluated Db2 pureScale — IBM's active-active high availability for Db2, conceptually comparable to Oracle RAC — they probably ruled it out over the hardware requirements. That was a valid criterion in 2022. It no longer is.

What your team assumespureScale requires specific on-premises hardware, InfiniBand interconnect and a complex infrastructure project.
What Db2 12 offerspureScale self-managed on Azure and AWS. On AWS, EFA cuts latency by 40% and multiplies throughput by 2.5×. Mixed HADR topology for DR with different node counts.
⚠The cost: ruling out an architecture over requirements that stopped applying years ago. A design decision made on 2022 information that limits the team's options today.
05

What your team assumes needs another database

A semantic search or RAG requirement comes up. The instinct is to assume you need another database: another vector engine, another backup, another monitoring system, another lifecycle to maintain. It may well be the right call. But it's worth knowing that Db2 12 already stores and queries vectors inside the same engine:

What your team assumesThat doing RAG needs another database, another backup, another monitoring system and another lifecycle to manage.
What Db2 12 hasNativeVECTOR datatype (12.1.2). DiskANN indexing(12.1.5). SQL Functions TO_EMBEDDING y TEXT_GENERATION that invoke watsonx.ai or OpenAI models directly from a SQL query.
⚠The native option won't always be the best. But one less system to maintain, back up and monitor is an architecture decision worth evaluating — especially if the team didn't even know it was on the table.
The pattern

It's not a competence problem. It's an information problem.

All five cases share the same root cause: the team isn't doing things wrong. They're doing them as they were taught. The problem is that the product has changed and nobody told them. IBM has shipped six mod packs since November 2024. The procedures the team learned — whether on version 10 or 11.5 — no longer reflect how the engine works today.

And here's what matters: most of these problems aren't solved by buying hardware or adding headcount. They're solved by updating procedures. The risk isn't running Db2 badly — it's running Db2 12 as if it were Db2 11.5.

We've built two in-house courses that cover exactly this gap. They're not generic: they're updated to Db2 12.1.5, delivered on AIX and Linux, and tailored to the team's level. On-site or remote, in English, Spanish and French.

Administration · Db2 12 LUW IBM Db2 12 Administration for AIX and Linux Deployment, storage, backup, security, performance and the new Pacemaker-based high availability with HADR. Eight modules focused on hands-on DBA practice. View the course Advanced · Db2 pureScale Db2 pureScale Deployment and Administration Multiple Db2 instances sharing a filesystem with Storage Scale (GPFS) in active-active mode. Nine modules, from cluster design to production operations. View the course
FAQ

FAQ

Has Pacemaker replaced TSAMP in Db2 12?

Yes, on Linux. Pacemaker replaces Tivoli System Automation as the cluster manager for HADR. Configuration, validation and failover procedures change entirely. On AIX, the right option for critical workloads is PowerHA SystemMirror — the product IBM actively develops for Db2 HA on Power. TSAMP is the layer to avoid on both platforms.

What does Db2 12 automate that used to be manual?

Multi-threaded backups with no extra configuration, history file maintenance decoupled from backup execution, online schema evolution on columnar tables, automatic archive log pruning and online index reorg without blocking.

Is there up-to-date Db2 12 training for AIX and Linux?

Yes. At SIXE we offer two in-house courses: Db2 LUW administration and pureScale deployment and administration. On-site or remote, in EN/ES/FR.

Can Db2 pureScale be deployed in the cloud?

Yes, since Db2 12. Self-managed on Azure (RoCE and TCP/IP, BYOL) and on AWS (with Elastic Fabric Adapter). Dedicated on-premises hardware is no longer required.

Db2 12 Training · AIX and Linux

Is your team running Db2 without having caught up with v12?

Tell us which version you're on, how many DBAs need training and on which platform. We'll put together a tailored proposal — syllabus, format, dates and language.

Request a quote WhatsApp View LUW course

OWASP API Security Top 10 vs IBM API Connect

/in
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●

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.

10
Critical risks
in the OWASP list
2023
Latest current
OWASP edition
4 / 10
Native coverage
by IBM gateway
3
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: .

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

/in
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●

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.

INFORMIX VERSIONS · STATUS IN 2026 12.10 EOS · 30-Apr-2026 Extended Support only (through 2030) 14.10 xC13 · Jan 2026 Supported version 15 Active line · Nov 2024 No internal limits → recommended migration → → upgrade path →
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
Inherited
Removed
External smartblobs
No
No
Yes
watsonx.data integration
Limited
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: .

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

/in ,
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●

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.

10
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
01
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.
02
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.
03
Asset and supplier inventory
Asset list including criticality; supplier list flagging critical ICT providers with the NIS2 contract clauses (notification, audit rights, exit plan).
04
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.
05
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.

01

Information security policy (board approved)

02

Risk assessment and treatment plan

03

Asset inventory with criticality

04

Critical ICT supplier register + NIS2 clauses

05

Incident response procedure + runbooks

06

Business continuity and DR plans

07

Backup strategy + last restore test record

08

Vulnerability management policy and reports

09

MFA enforcement evidence on privileged access

10

Executive training records (Art. 20.2)

11

Recent incident notifications filed

12

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:

  1. Gap assessment against Article 21 — mapping existing ISO 27001 / NIST CSF / ENS controls and producing the inspection-ready artefacts.
  2. Governance and executive training — wording for the board approval minute, training content for management bodies (Art. 20.2 evidence).
  3. 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.
  4. 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.
  5. MFA enforcement. Particularly painful in IBM Power estates — PowerSC for AIX and IBM i covers that layer with compliance integration.
  6. Supplier register and contract clauses. Critical ICT provider inventory and NIS2-aligned clauses — the supply chain measure (4) is where most teams fall short.
  7. 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

/in
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●
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
01
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.
02
Your view from the fieldMaturity of open source on Power, recommendation (NPS 0–10), community health, skills market, real production usage patterns.
03
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.
04
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.
05
Trust in each actorIBM, Red Hat, SUSE, Canonical, independent maintainers, ISVs, Business Partners. You only rate the groups you have a basis to judge.
06
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

/in
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●

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
0
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 Reef 18.x · 2023 EOL Squid 19.x · 2024 Active Tentacle 20.x · Nov 2025 Recommended U 21.x · ~2027 → upgrade → → upgrade →
Ceph release timeline — sequential upgrades only. Each major version is supported for approximately 2 years.
CEPH UNIFIED STORAGE ARCHITECTURE RADOS Reliable Autonomic Distributed Object Store RBD Block Storage RGW S3 Object Storage CephFS POSIX File System OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD Distributed across commodity hardware — no single point of failure VMs · Kubernetes · DBs Backups · AI Data · Media HPC · CI/CD · Shares
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
S3
POSIX, NFS, S3
Complexity
Medium–High
Low
High
Kubernetes native
Rook (CNCF)
Operator
CSI driver
Licence cost
Open source
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: .

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

/in
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●

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?".

4
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:

  1. The bill goes up. Switching to a bundle with components you don't use (vSAN, NSX, Aria) multiplies the per-core cost.
  2. The clock is ticking. Multi-year contracts expiring, and the classic email of "your renewal is in 90 days, please confirm".
  3. 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?
02Where is your platform heading in the next 3 years?
03How "VMware-heavy" is your stack today?
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
1
Real estate inventory

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

2
Upper-stack dependency map

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

3
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).

4
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.

5
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)

/in
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●

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 LIFECYCLE — DEBIAN 12 vs DEBIAN 13 20232025202620282030 TODAY Debian 12 "Bookworm" LTS → Jun 2028 Debian 13 "Trixie" → Jun 2030 Full support LTS
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
1
Patch BookwormStart from a 100% up-to-date system
2
Repos to Trixiebookworm → trixie (incl. trixie-security)
3
Disable third-party reposRe-enable them one by one afterwards
4
Minimal + full upgrade--without-new-pkgs then full-upgrade
5
Clean upautoremove + autoclean
6
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
10 yrs
Packages
~59,000
~30,000
~5,000
Licence cost
€0
Per node
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.

SIXE engineer upgrading a server from Debian 12 Bookworm to Debian 13 Trixie in a data center
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: .

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

/in
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●

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
10
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
1
Audit active rulesWhich rules does someone actually look at? Not the default ones nobody touched in five years.
2
Translate rules to WazuhRewrite custom rules in Wazuh format + build decoders for your internal applications.
3
Export historical dataArchive past events in a neutral format. Without this, auditors see a gap in your records.
4
Run in parallel for 4–6 weeksBoth SIEMs operating simultaneously. Validate that Wazuh captures everything the old one did.
5
Validate with your auditorOptional but recommended. Get sign-off before decommissioning the old system.
6
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:

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
SIXE