AI Act: what actually applies on 2 August 2026

/in
AI Act · July 2026

AI Act 2 August: what actually applies (and what slid to 2027).

For months, 2 August was "high-risk day". Not anymore: the Digital Omnibus pushed that to December 2027. But it left Article 50 intact — the one that forces your chatbots to identify themselves, your AI-generated content to carry a machine-readable mark, and your deepfakes to be labelled. If your product talks, writes or draws, it's time to land the technical side with EU AI Act compliance consulting.

8 min read ●AI Compliance ●

Regulation (EU) 2024/1689 — the AI Act — had its schedule moved a month ago and most of the market has yet to notice. The Digital Omnibus, approved by the Council of the European Union on 29 June 2026, pushed the Annex III high-risk obligations from 2 August 2026 to 2 December 2027. But Article 50 — transparency — kept its original date. In EU AI Act consulting we have been preparing this technical side since spring with clients who saw it coming.

The three dates that matter
2 Aug 2026Applies now
Article 50 · Transparency. Chatbots must identify themselves, AI-generated content must be marked machine-readable, deepfakes must be labelled. Fines up to €15M or 3% of global annual turnover.
2 Dec 2026This autumn
Article 5 · New prohibition. AI systems generating non-consensual intimate imagery are banned. Applies to every operator, regardless of the system's risk level.
2 Dec 2027+16 months
Annex III · High risk. HR, credit, biometrics, education, essential services. Deferred from 2 August 2026 by the Digital Omnibus.
01 · Context

What was supposed to happen on 2 August

Until 29 June, the AI Act calendar was known and boring: 2 August 2026 was the day the obligations for the systems under Annex III kicked in — biometrics, HR, credit decisions, formal education, critical infrastructure, law enforcement and essential services.

That meant, for any operator with a system classified as high risk, wiring up in production a nontrivial pile of things: risk management, data quality and bias governance, technical documentation, automatic event logging, user-facing transparency, effective human oversight, accuracy and cybersecurity, and post-market monitoring. All with technical evidence sitting on your own code and your own infrastructure.

None of that applies in August anymore. But part of what was expected — Article 50 — is still exactly on its original date.

02 · Digital Omnibus

What changed on 29 June

The Digital Omnibus is the digital simplification package that the Council of the European Union approved on 29 June 2026. It is an amendment to the AI Act itself. Its declared aim: ease the applicability calendar in the face of clear evidence that neither companies nor competent national authorities were going to arrive in August with the technical and supervisory structures ready.

The most visible measure: the Annex III high-risk obligations, originally due to enter into force on 2 August 2026, are deferred to 2 December 2027. Sixteen more months.

Not an amnesty

It's a deferral, not an exemption. Neither the substance of the regulation nor its obligations change. What changes is when they are enforceable. If your system classifies as Annex III high risk, the technical work is the same — you just have sixteen more months to make it presentable. That margin evaporates quickly once you open the code base.

What did not change with the Digital Omnibus matters just as much: Article 50 transparency keeps its original date. And the new Article 5 prohibition on non-consensual intimate imagery also stays on schedule, for 2 December 2026.

03 · Article 50

The three things that do come into force

Article 50 of Regulation (EU) 2024/1689 imposes transparency obligations on providers and operators (deployers) of AI systems — regardless of whether the system is high risk or not. Three blocks. Specific ones.

50 · 1

Chatbot identifies itself

AI systems designed to interact with people must inform the user that they are talking to an AI, unless it is obvious from context. Applies to customer support chatbots, conversational assistants, IVR with synthetic voice and in-app agents. UI translation: a clear opening message, not a footnote in the footer.

50 · 2

Marking of generated content

Providers of generative AI (text, image, audio, video) must mark their outputs in a machine-readable format so that they can be detected as artificially generated or manipulated. The obligation sits on the model provider, not on the end user asking for an image.

50 · 4

Labelled deepfakes

Deployers using AI to create deepfakes (image, audio or video that falsely resembles a real person, object or event) must label the content as artificially generated or manipulated. There are narrow exceptions for artistic, satirical or law enforcement use — not a blank cheque.

Extraterritorial scope

Article 50 applies to any AI system placed on the market or put into service inside the EU, regardless of when it was placed on the market or whether the provider is established in the EU. A model trained in California and offered via SaaS to European customers is in scope. Living outside the EU does not spare you the fine if your outputs reach us.

04 · Penalties

How much ignoring it costs

The AI Act orders penalties into three tiers (Article 99). Worth not mixing them because the big headline number circulates a lot.

€35M · 7%
Prohibited practices
(Article 5)
€15M · 3%
Article 50 and other
infringements
€7.5M · 1%
Incorrect information
to the authority

Article 50 infringements fall in the second tier: up to €15 million or 3% of the previous financial year's global annual turnover — whichever is higher. Supervision and sanctions are run by the national competent authority in each member state; the specific body (and its readiness) varies country by country.

05 · Quick check

Does Article 50 apply to you?

Three short questions and you will know whether you have work ahead or you can breathe until high-risk hits in 2027.

Three-click check

No telemetry, no cookies, nothing sent anywhere. Everything runs in the browser.

1. Does your product have a chatbot, conversational assistant or IVR with synthetic voice that talks to real people?

2. Does your product generate text, images, audio or video with AI that end users see or download?

3. Does your product create or distribute deepfakes — image, audio or video that resembles a real person, object or place?

Article 50 does apply — and on several fronts.

With two or three blocks ticked, you have obligations around chatbot disclosure, content watermarking and/or deepfake labelling. It's the densest scenario: UI to touch, generation pipeline to touch, auditable logs to leave behind. With focus and priority, a week is enough to land the minimum starting with what's most visible to the user.

→ AI Act assessment with SIXE

Article 50 applies in one specific block.

You have a clear obligation. If the yes was the chatbot, the heavy lifting is UX: a clear opening message plus a log. If it was content generation, the heavy lifting is technical: C2PA + watermark + logging. If it was deepfakes, the heavy lifting is process: systematic labelling in the publication pipeline.

→ AI Act assessment with SIXE

You can breathe on Article 50.

No chatbot, no user-facing AI-generated content and no deepfakes — this block does not apply. But careful: if your AI falls under Annex III (biometrics, HR, credit, education, critical infrastructure, essential services) you have a date with the high-risk obligations on 2 December 2027. And that, when you get into it, is much more work than a chatbot notice.

→ Review Annex III classification

06 · Watermarking

The real problem: no single tech does the job

Obligation 50(2) — marking AI-generated content in machine-readable format — sounds like a label problem. It isn't. The regulation asks for four properties at once that no known technology satisfies together: imperceptibility (don't degrade the content), robustness (survive compression, editing, screenshots), detectability (verifiable downstream) and traceability (identify generator and version).

The practical approach that serious providers are adopting is layered. Three layers, each covering the failure modes of the previous one.

Layer 1

C2PA metadata

Content provenance standard driven by Adobe, Microsoft, Sony and others. Cryptographically signs metadata that travel with the file: who generated it, with which model, when. Survives compression. Disappears with screenshots or re-encoding without signing — i.e. with almost any social post.

Layer 2

Imperceptible watermark

SynthID (Google DeepMind) for images and audio, similar techniques for text and video. Modifies the output imperceptibly so a detector can recognise it. Survives screenshots, but degrades under aggressive manipulation, heavy cropping or source mixing.

Layer 3

Generator-side logging

Audited log on the provider side: what was generated, when, with which prompt, model and version. The most boring, the most important, and the one that lets you respond to a request even after layers 1 and 2 have evaporated along the way.

SIXE angle

Layer 3 — generator-side logging — is where running AI on-premise becomes a real advantage rather than a marketing line. On your own inference stack you can log every prompt, every output, every model and every version without depending on a SaaS provider's audit trail that they show you when they feel like it. And in RAG with Docling, the traceability of which document fed which answer is part of the architecture by design.

07 · Checklist

The minimum to have in place

If the quiz said Article 50 applies to you, this is the checklist with the essentials. Tick what you already have. What remains unticked is your backlog — and what we build with clients in a kick-off consulting engagement.

Article 50 checklist · 7 items

0/7 done
  • "You're talking to an AI" notice on your chatbotsClear opening message, not a footnote in small print. Applies to voice assistants and synthetic IVR too.
  • Chatbot session logDate, system, model version, session ID. If the authority asks, you must be able to show that the disclosure went out.
  • C2PA on generated outputsCryptographically signed metadata on images, audio and video. Layer 1 of layered watermarking.
  • Imperceptible watermarkSynthID or equivalent for what C2PA loses when someone takes a screenshot and shares it on social media.
  • Generator-side loggingAuditable log of prompts, outputs, model and version on your side. Boring to implement, essential when it's time to demonstrate. On on-premise inference over Ceph, OpenStack or K8s it stays inside your perimeter.
  • Deepfake labelling in the pipelineIf you generate or distribute content that resembles real people, label it inside the publication flow itself. Don't leave it to the editor on duty. With safe AI agents labelling runs as policy, not as a reminder.
  • Internal conformity documentHalf a page explaining which obligations apply to which systems, who is accountable and where the logs live. This is where ISO 42001 chains naturally with the AI Act.
All seven ticked. If it's real and not vibes, your week is looking good. If any were missing, EU AI Act consulting starts from there.
08 · December 2026

The other date almost nobody is watching

Four months after the Article 50 deadline, on 2 December 2026, a new prohibition added by the Digital Omnibus to Article 5 takes effect: AI systems that generate non-consensual intimate imagery join the regulation's catalogue of prohibited practices.

Because it is a prohibition, it doesn't admit exceptions by size or by prior risk level of the system. It applies to every operator on the European market — providers, deployers, importers, distributors — no exception. No intermediate Annex, no additional grace period. Prohibited.

This hits products and services like generators of real-person imagery without consent, face-swap apps on intimate content and nudify tools that have proliferated in the last two years. General-purpose model providers are affected indirectly through foreseeable uses: if your model can be reasonably used for that, technical safeguards stop being optional.

09 · Architecture

Why on-premise makes the paperwork easier

None of the Article 50 obligations depend on where the AI runs — they apply to providers and deployers regardless of topology. But demonstrating compliance does depend. And that's where deploying on your own infrastructure plays in your favour for very practical reasons:

  • Generator-side logging (layer 3) lives in your system, with your retention policies, without third-party access agreements or SaaS dashboard export limits.
  • Technical documentation of the model — which if the risk tier climbs is demanded in detail — is under your control: weights, training data provenance, evaluations, version. Nothing depends on your cloud provider's goodwill.
  • Data governance is demonstrated on data that never left your perimeter. For healthcare, banking and public sector it is a de facto requirement — the AI Act just puts it in writing.
  • Auditable agents with OPA, LangChain or CrewAI fit naturally with the effective human oversight that high risk will require in 2027.
FAQ

Frequently asked questions

What comes into force under the AI Act on 2 August 2026?

The Article 50 transparency obligations. Chatbots must let users know they are talking to an AI; AI-generated content (text, image, audio, video) must be marked in a machine-readable format; deepfakes must be labelled as artificially generated or manipulated. Non-compliance is fined up to €15 million or 3% of global annual turnover, whichever is higher (Article 99.4).

Has enforcement for high-risk systems been delayed?

Yes. The Digital Omnibus, approved by the Council of the European Union on 29 June 2026, postponed the Annex III obligations (biometrics, HR, credit, education, critical infrastructure, law enforcement, essential services) from 2 August 2026 to 2 December 2027.

Article 50 has NOT been postponed and still applies on 2 August 2026.

What is the Digital Omnibus?

The digital simplification package approved by the Council of the European Union on 29 June 2026 that delays the applicability of several AI Act obligations and clarifies operational aspects of the regulation. Its most significant measure is deferring the Annex III high-risk obligations to 2 December 2027.

How much does breaching Article 50 cost?

Up to €15 million or 3% of the previous financial year's global annual turnover, whichever is higher (Article 99.4). It is the second tier of penalties. The first tier (€35M or 7%) is reserved for the prohibited practices under Article 5 — a separate matter.

How do you meet the machine-readable marking requirement?

With a three-layer approach: cryptographically signed C2PA metadata in the file; imperceptible watermark like SynthID for what C2PA loses on screenshots; and audited logging in the generator itself. No single layer covers the four requirements the regulation demands — imperceptibility, robustness, detectability and traceability.

What new prohibition comes into force on 2 December 2026?

Article 5 adds a new prohibition: AI systems that generate non-consensual intimate imagery. It applies to every operator regardless of the system's risk level.

Does the AI Act apply if my AI is on-premise?

Yes. The AI Act applies to any system placed on the market or put into service in the EU, regardless of where it is deployed or where the provider is established. Running AI on-premise does not exempt — but it makes the demonstrating side easier: logging, traceability and audit are yours, not a third party's.

Are AI Act, NIS2 and ISO 42001 the same thing?

No, but they support each other. NIS2 is the European cybersecurity directive — it forces you to manage risk and notify incidents. ISO/IEC 42001 is the international standard for AI management systems — a governance framework. The AI Act is European law with specific obligations by risk level. All three overlap in data governance, traceability and logging: doing one properly covers part of the next.

Technical compliance

Does your product talk, write or draw with AI?

We land which Article 50 obligations apply to your systems, review chatbots and generators, set up the inference pipeline with auditable logging and roll out layered watermarking. We handle the technical side; legal interpretation stays with your legal advisors.

EU AI Act consulting → See AI solutions

Storage for AI and HPC: Ceph, Lustre, GPFS or DAOS?

/in
Infrastructure · AI / HPC storage · Open Source

Storage for AI and HPC in 2026: Ceph, Storage Scale, Lustre, DAOS and BeeGFS.

You build a GPU cluster that costs as much as a building, and then you decide where the data lives. That decision — the file system — is what determines whether your GPUs compute or wait. We map the five big options, what each is good for, and how not to get it wrong.

12 min read●Technical comparison●

There's a scene that repeats itself whenever we review an AI or HPC platform. The client proudly shows us the shiny new GPU cluster. Impressive TFLOPS figures. And then we ask the boring question: "and where do they read the data from?" Far too often, the answer is an NFS share bolted onto a box in the corner.

Buying eight GPUs that cost as much as a house and feeding them over NFS is the digital equivalent of putting a moped's fuel tank on a Formula 1 car: all the power is there, but it spends the day in the pits. Storage is what decides whether those GPUs work or wait — and getting it right starts with knowing what your options are and what each one is for.

1 & 2
DAOS positions on the
IO500 production list (SC25)
×4
Their combined score vs.
the next 30 systems
#1
Lustre, the most widely used
FS in supercomputing
50+ PB
Ceph deployed
at CERN
01 · The vocabulary that shapes the architecture

Four concepts before comparing anything

Distributed storage piles up jargon fast, and marketing labels don't always help. Before we get into it, it's worth pinning down four ideas — they're the ones that actually separate one system from another when it's time to choose.

Parallel POSIX vs. object A parallel file system (paths, permissions, open()/read()) spreads each file across hundreds of servers that serve it at once: it's what classic HPC software expects. Object storage has no directories, just keys and objects over an S3 API: it's the language of data lakes and modern AI.
Bandwidth vs. IOPS Classic HPC wants sequential GB/s to dump huge checkpoints. AI training often wants the opposite: millions of tiny files read at random, where IOPS and metadata performance rule. Almost no system is king of both.
Metadata rules The metadata server (MDS) is what knows where everything lives. In AI workloads with millions of small files, it's usually the first bottleneck, before the disk. Plenty of migrations fail by sizing the disk well and forgetting the metadata.
GPUDirect Storage A direct path between storage and GPU memory, skipping the CPU and any intermediate RAM buffer. Lower latency, less CPU burned shuffling bytes, and GPUs that stop waiting. It's the piece modern AI demands from storage.
The distinction that matters

The best storage is the one that fits your dominant workload. If your day-to-day is simulations writing giant files, you want sequential bandwidth. If it's training models over millions of images, you want fast metadata and IOPS. Mixing the two up is the most expensive design mistake we see.

02 · The five contenders

Who plays in which league?

Here are the five systems that dominate serious storage for AI and HPC. There's no single winner: each has a sweet spot. The bars compare, roughly, two axes that are almost always in tension: the peak performance a system can reach and how easy it is to operate day to day.

Ceph
Unified · object + block + file Peak performance Versatility / ops
The Swiss army knife
Storage Scale
Parallel POSIX · GPFS · IBM Peak performance Support / ops
The enterprise workhorse
Lustre
Parallel POSIX · the TOP500 one Peak performance Ease of operation
The HPC standard
DAOS
Object / KV on NVMe Peak performance Ease of operation
The IO500 rocket
BeeGFS
Parallel POSIX · easy to deploy Peak performance Ease of operation
The quick-deploy one
Indicative bars · the best system is the one that fits your workload, not the one with the longest bar
03 · The table you can show in a meeting

Five systems at a glance

The essentials of each one: what type of storage it is, where it shines, the license it ships under, and which version is in production as of mid-2026.

SystemTypeSweet spotLicenseVersion (2026)
CephUnifiedHybrid AI + HPC platforms, private clouds, S3 data lakes. Object, block and file from a single cluster.Open source LGPL20.2.2 "Tentacle" (Jun 2026)
IBM Storage ScaleParallel POSIXEnterprise HPC with support and SLAs, AI on NVIDIA DGX BasePOD/SuperPOD, high performance out of the box.Commercial IBM5.2.x
LustreParallel POSIXClassic max-bandwidth supercomputing. The TOP500 standard when you have a team that knows how to run it.Open source GPLv22.17 (Dec 2025)
DAOSObject / KVExtreme performance on pure NVMe. The fastest thing on the IO500, for workloads where latency is everything.Open source BSD2.6
BeeGFSParallel POSIXMid-to-large HPC clusters and research groups that want good performance without a dedicated storage team.Community + Enterprise8.3.x
04 · One by one

What each does well (and what it doesn't)

Ceph — the one that does almost everything

Ceph is the Swiss army knife of open source distributed storage: it serves object (S3 via RGW), block (RBD) and file (CephFS) from the same cluster, self-heals, and scales by adding nodes. For AI that means RBD for the training boxes, S3 for the data lake and CephFS for parallel access — with native OpenStack and Kubernetes integration. It isn't the peak-performance king in extreme HPC, but nothing matches its versatility, and deployments like CERN's 50+ PB prove it holds up at serious scale. Version 20.2.2 "Tentacle" (June 2026) brings Crimson for erasure-coded pools and RGW encryption improvements. It's also the natural winner of the gap MinIO left when it went into "maintenance mode" in late 2025. We dig into all of this in our guide to open source storage for AI and HPC. At SIXE we work with it daily: Ceph for AI & HPC and official Ceph training.

IBM Storage Scale (GPFS) — performance with an SLA

Once GPFS, then Spectrum Scale, and today IBM Storage Scale: the same workhorse with three names. It's a mature, POSIX parallel file system with enterprise support that, in version 5.2.x, integrates NVIDIA GPUDirect Storage and certification for DGX BasePOD/SuperPOD and Grace Blackwell platforms. It's the choice when you want the performance of a parallel FS but don't want to depend on your team being able to rebuild a Lustre at three in the morning: you pay for the license, you get the SLA. We build HPC infrastructure with Storage Scale + Spectrum LSF/SLURM and run Storage Scale administration training.

Lustre — the TOP500 standard

Lustre is still, by a wide margin, the most widely used file system in supercomputing: it moves a huge share of the world's largest compute centres. It delivers extremely high sequential bandwidth and scales to exabytes. The price is operations: it's not "install and forget", and it takes real expertise to tune and recover. Version 2.17 (December 2025) continues that line, with 2.18 preparing file-level erasure coding (FLR-EC) and client-side compression. If you're coming from Lustre and want commercial support, we've written about migrating from Lustre to IBM Storage Scale.

DAOS — the rocket that came back

DAOS is the answer to "what if we throw POSIX out and design for NVMe from scratch?" The result: it holds positions 1 and 2 on the IO500 production list (Argonne and LRZ, SC25), and 16 of the top 30 in the full ranking run DAOS. It was born tied to Intel's Optane memory; when Intel killed Optane, many wrote DAOS off too. But since version 2.6 (July 2024) it runs on plain NVMe SSDs and is very much alive. It's now governed by the DAOS Foundation under the Linux Foundation (Argonne, HPE, Google Cloud, Intel), after Intel handed its team to HPE in 2024. It's the top-performance option for anyone with pure NVMe and a workload that justifies it — not a general replacement.

BeeGFS — the easy one to live with

BeeGFS is the parallel FS that prioritises being deployable on a Tuesday afternoon without a PhD in storage. It delivers very good performance for mid-sized clusters and is a favourite of many research groups for its simplicity. Watch out for one important change: since BeeGFS 8 the Community Edition is still free but requires generating a community license (beegfs license), and enterprise features sit behind a paid license. The stable release in 2026 is 8.3.x.

The recurring pattern

Notice the tension: Lustre and DAOS deliver top performance but demand an expert team. Storage Scale buys that performance with a license and support. Ceph and BeeGFS give up a little peak in exchange for an easier life. No option is free: each one trades performance for simplicity, or license cost for support.

05 · The axis that really decides

Is your workload classic HPC or AI?

Before you look at brands, look at your workload. The question that orders the decision isn't "which is best?" — it's what you're going to ask of the storage. Here are the two profiles and what each one needs.

Classic HPC
  • Simulation, CFD, molecular dynamics, weather
  • Writes huge checkpoints sequentially
  • What it wants: sustained GB/s of bandwidth
  • Large files, more predictable access
  • Fits: Lustre, Storage Scale, BeeGFS
AI / ML workload
  • Training and inference over massive datasets
  • Reads millions of small files at random
  • What it wants: IOPS, fast metadata and GPUDirect
  • Must feed the GPUs without leaving them idle
  • Fits: DAOS, Storage Scale, Ceph (S3)

Most modern platforms mix the two, which is why open source storage for AI and HPC tends toward hybrid architectures: a parallel FS for the compute side and S3 object storage for the data lake, often coexisting on Ceph + OpenStack + Kubernetes.

06 · How to choose without regret

Four steps before signing anything

Define your dominant workload

Before looking at products, measure. Do you write a few giant files or read millions of small ones? Is bandwidth or metadata the bottleneck? That single answer already rules out half the options. And don't just plan for today: size for the workload you'll have once the AI project grows.

Decide: open source with a team, or support with an SLA

Lustre and DAOS are free to license but expensive to operate: you need people who know them. Storage Scale flips that equation: you pay for the license and buy peace of mind. Ceph and BeeGFS sit in between. The honest question is: do you have — or want to have — a storage team?

Look at the ecosystem you already run

Already running OpenStack or Kubernetes? Ceph fits like a glove. Have NVIDIA DGX / BasePOD? Storage Scale is certified. Pure NVMe and thirsty for latency? DAOS. The best storage is usually the one that creates the least friction with what's already in production.

Test at scale before you commit

A four-node benchmark won't predict how forty nodes behave. Test with your real workload, not the datasheet's synthetic one, and watch the metadata under concurrency. Experience here saves months — and a six-figure wrong purchase.

Where SIXE comes in

Designing the storage layer of an AI or HPC platform, comparing Ceph, Storage Scale, Lustre, DAOS or BeeGFS for your case, or migrating from one to another without losing data or sleep — at SIXE we've spent more than 15 years at the crossroads of distributed storage, IBM Power and open source. See Ceph support and IBM Storage.

Summary

The essentials in 5 points

To take away from this post

→ Storage decides whether your GPUs work or wait. It's as strategic as the compute cluster itself.

→ There's no "best": there's the best for your workload. Classic HPC wants bandwidth; AI wants metadata, IOPS and GPUDirect.

→ DAOS leads on performance (1st and 2nd on the IO500), Lustre on prevalence, Storage Scale on enterprise support.

→ Ceph is the versatile choice for hybrid AI + HPC architectures; BeeGFS, the easiest to deploy.

→ Before choosing: define the workload, decide open source vs. SLA, look at your ecosystem, and test at real scale.

FAQ

Frequently asked questions

What is better for AI, Ceph or Lustre?

It depends on the workload. Lustre delivers more sequential bandwidth and is the standard in classic supercomputing, but it takes real expertise to operate. Ceph is more versatile: it serves object (S3), block and file at once, integrates with OpenStack and Kubernetes, and its object storage fits AI data lakes. For large-scale training with huge checkpoints, choose Lustre or Storage Scale; for hybrid platforms and data lakes, Ceph.

Is DAOS ready for production?

Yes, in its niche. It holds positions 1 and 2 on the IO500 production list (SC25) and is governed by the DAOS Foundation under the Linux Foundation. Since version 2.6 (July 2024) it runs on plain NVMe SSDs, without Optane. It's the top-performance option, but it needs NVMe hardware and a skilled team; it's not a general replacement for Lustre or Ceph.

Is Storage Scale the same as GPFS or Spectrum Scale?

Yes. It's the same IBM product under different names: GPFS, then IBM Spectrum Scale, and today IBM Storage Scale. In 2026 it's on 5.2.x and supports NVIDIA GPUDirect Storage and DGX BasePOD/SuperPOD certification.

Is BeeGFS still free?

The Community Edition is still free, but since BeeGFS 8 you have to generate a community license with beegfs license. Enterprise features sit behind a paid license. The stable release in 2026 is 8.3.x.

Can you use Ceph for serious HPC?

Ceph appears on the IO500 production list and there are massive deployments (CERN runs over 50 PB), but for extreme-performance HPC it usually doesn't replace Lustre, Storage Scale or DAOS. Its strength is hybrid HPC + AI architectures: object, block and file from a single cluster, integrated with OpenStack and Kubernetes.

AI / HPC storage · Open Source

Do your GPUs compute or wait?

Tell us what workload you're moving, how many GPUs, and what you run today. We'll get back to you within 24 hours with a storage architecture sketch and a realistic idea of effort. If Ceph fits, we'll tell you. If yours is Lustre, Storage Scale or DAOS, we'll tell you that too.

See AI/HPC storage Contact

IBM QRadar, G2 Leader in SIEM, UEBA, NTA and IR 2026

/in
Cybersecurity · IBM QRadar · SOC

IBM QRadar makes G2 Leader in four categories at once.

SIEM, UEBA, Network Traffic Analysis and Incident Response. We walk through what each category actually measures, what it means for a real SOC, and which QRadar 7.6 courses we have on the shelf — so the badge doesn't just end up living on a slide deck.

8 min read●Technical analysis●

On 10 July, IBM announced that QRadar SIEM has again been named a G2 Grid Leader in four categories: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) and Incident Response. The official post is short — it tells you about the medals and moves on.

We'll take them one at a time. What G2 actually measures in each of the four, what it means for a SOC that has to run them day to day, and which version of QRadar our training covers (all three courses are on 7.6, the current release).

01

The four G2 wins, one at a time

G2 scores software from verified reviews left by people running it in production. Being a Leader in all four categories at once is a specific signal: these are four capabilities that used to come as separate products, and here they live inside the same platform.

Category 01 SIEM

Security Information and Event Management. Collects logs from systems, network, applications and cloud, normalises them, correlates them and detects patterns that point at incidents.

QRadar's home turf. Banks, telcos and government have been running it here for more than a decade. The surprise isn't this one — it's that QRadar also comes out on top in the other three.

Category 02 UEBA

User and Entity Behavior Analytics. Analyses the behaviour of users and assets, builds a baseline of "what normal looks like" and raises an alarm when something drifts off it.

This is what spots a user who's never moved more than 200 MB suddenly pulling down 300 GB at three in the morning. It used to require a separate UEBA product; in QRadar it ships as an integrated app.

Category 03 NTA · Network Traffic Analysis

Network traffic analysis. Looks at flows (NetFlow, IPFIX and equivalents) to detect lateral movement, exfiltration or command-and-control chatter that doesn't show up in logs.

The QRadar Network Insights module. Logs tell you what happened on the boxes; NetFlow tells you what went over the wires. Skip the second half and you're watching half the film. Particularly useful for teams who had NetFlow analysis living in a separate console.

Category 04 Incident Response

Response to incidents. Detection is half the job. The other half is orchestrating the response: playbooks, tickets, containment and coordinated comms between teams.

This is QRadar SOAR (formerly Resilient), which ranks as a G2 Leader in its own right, separate from the SIEM. It's the piece gaining the most weight in Europe since NIS2 started requiring incident notification within 24 hours — a window that gets tight quickly if your playbook lives on a Post-it note.

02

What a G2 Leader ranking actually certifies

G2 is, if you'll indulge the analogy, the TripAdvisor of enterprise software. And like TripAdvisor: if four hundred users all agree the paella was good, something's being done right. It still doesn't make it a Michelin guide.

Translated to QRadar: the reviews confirm that the people running it in production rate it well on satisfaction, integration ecosystem and ability to scale. What they don't confirm is that it's equivalent to a Gartner Magic Quadrant or a Forrester Wave, which are analyst assessments. Two different signals, both useful.

The same reviews also flag what the official post skips over: QRadar has a learning curve, initial tuning is demanding, and EPS/FPI licensing can grow faster than expected if the sizing isn't done properly. None of that is a product weakness — it's a familiar list of things we've seen up close, and all three tend to sort themselves out with training and planning.

03

Why the G2 wave lands at a useful moment

The European calendar has been busy. NIS2 has been in force since 2024 and 2026 is the year of inspections and enforcement against essential and important entities. DORA requires financial firms to demonstrate ICT operational resilience, including the ability to detect, notify and respond to incidents within measurable timings. Either way, having a SIEM installed isn't enough: you need a tuned SIEM and a SOC that knows how to run it.

Which is where the G2 wins earn their keep: as a hint of what's worth learning. If those four categories are the ones users rate highest on satisfaction — SIEM, UEBA, network traffic and response — then training your team on QRadar covers all four layers in one go. One course, four capabilities: the sort of ratio that tends to survive a training budget review.

04

Three courses aligned to the latest QRadar (7.6)

The three SIXE IBM QRadar training courses are aligned to the latest product release, 7.6. They can be taken standalone or as a pathway. On-site or remote, delivered in English, Spanish or French, with proprietary material and labs on QRadar 7.6 — the real product, quirks and all.

Fundamentals · BQ205G IBM QRadar SIEM 7.6 · Fundamentals course Architecture, offenses, rules, AQL searches and dashboards. The baseline course for L1 and L2 analysts who will be running QRadar day to day in the SOC. See the course Administration IBM QRadar SIEM 7.6 · Deployment & administration Installation, tuning, user and domain management, log source integration, high availability and updates. For whoever has to keep the engine running in production. See the course Advanced operations IBM QRadar SIEM 7.6 · Advanced operations UEBA, Network Insights, threat hunting with advanced AQL, SOAR playbooks and MITRE ATT&CK integration. For the mature SOC looking to extract real performance from the engine. See the course
FAQ

Frequently asked questions

Which G2 categories is IBM QRadar a Leader in for 2026?

Four critical security categories: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) and Incident Response. Recognition is based on verified customer reviews and market presence, not on independent analyst evaluation.

Is a G2 Leader ranking equivalent to a Gartner Magic Quadrant?

No. G2 collects verified reviews from real users; Gartner and Forrester rely on their own analysts. They're different, complementary signals: a product that scores well on both is usually a safer bet than one that only stands out on one.

Which QRadar version do the SIXE courses cover?

All three courses (Fundamentals, Deployment & administration, Advanced operations) are aligned to IBM QRadar SIEM 7.6, the current product release. Labs run on real 7.6 environments.

Are the QRadar courses delivered on-site or remotely?

All three courses can be delivered on-site at the client's premises or remotely in a virtual classroom, in English, Spanish or French. They adapt to the client's schedule and to the team's level, from L1 analysts up to senior administrators.

IBM QRadar 7.6 training · On-site or remote

So — how do we get from headline to production?

Tell us how many people need training, what roles they cover (analyst, administrator, architect) and which version you're on. We'll come back with a tailored proposal — syllabus, format, dates and language — in less time than a proper tuning pass.

Request a quote WhatsApp See QRadar training hub

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
SIXE