Elasticsearch Security Hardening Checklist

The most important Elasticsearch security measure in 2026 is simple: turn on the built-in security stack — and on Elasticsearch 8.0+ it is already on by default. Native authentication, role-based access control (RBAC), and TLS encryption have been free in the Basic tier since Elasticsearch 6.8 / 7.1 (May 2019) and enabled by default since 8.0 (2022). Security is no longer a paid add-on or an optional plugin. This post is a prioritized hardening checklist — the measures that matter most, in the order to apply them. For the click-by-click commands to enable each one, follow our companion walkthrough on securing Elasticsearch with built-in security.

Key takeaways

• Built-in security is free and default. TLS, native-realm authentication, and RBAC ship in the Basic tier; ES 8.x and 9.x turn them on automatically.
• Public exposure is the #1 risk. Unauthenticated, internet-facing Elasticsearch remains the classic cause of data breaches — bind to a private interface and firewall ports 9200/9300.
• Use API keys and least-privilege roles, never the elastic superuser, for applications and ingest clients.
• Back it up and watch it. Automate snapshots with Snapshot Lifecycle Management (SLM) and keep the cluster patched off end-of-life versions.
• Know your tiers. Most controls are free; field/document-level security and audit logging require a Platinum licence — OpenSearch offers comparable features free under AGPL/Apache.

Why is Elasticsearch security different in 2026?

Most older tutorials (this post included, in its original 2017 form) assume you bolt security on with a paid plugin called Shield. That advice is obsolete. Shield was renamed X-Pack Security in 5.0 (2016), the core controls became free in Basic from 6.8 / 7.1 (May 2019), and they are on by default from 8.0 (2022) with auto-generated certificates, an elastic superuser password, and enrollment tokens. So a 2026 hardening pass is no longer about installing security — it is about confirming it is enabled and then layering network, operational, and backup controls on top. (For the full naming timeline, see the step-by-step built-in security guide.)

The Elasticsearch hardening checklist

Work top to bottom — the highest-impact controls come first. Everything marked Basic is free; the how for each links to the step-by-step guide.

#	Measure	Why it matters	How / where	Tier
1	Enable built-in security + TLS	Encrypts node-to-node (9300) and client (9200) traffic; blocks anonymous access	xpack.security.enabled, xpack.security.transport.ssl, xpack.security.http.ssl; auto-configured on ES 8.x	Basic
2	Rotate built-in user passwords; use API keys for apps	Default/shared elastic credentials are a breach magnet	elasticsearch-reset-password; POST /_security/api_key	Basic
3	Least-privilege RBAC roles	An app or ingest client should never hold superuser rights	PUT /_security/role, role mappings, scoped privileges	Basic
4	Network isolation	Public, unauthenticated ES is the #1 cause of data leaks	network.host = private IP, firewall 9200/9300, reverse proxy for external access	Basic
5	Lock down scripting	Dynamic/inline scripts can be abused for RCE	Painless is sandboxed by default; keep script.allowed_types restricted	Basic
6	Automate snapshots (SLM)	Ransomware and fat-finger deletes need a clean restore point	Snapshot Lifecycle Management policy to S3/repo	Basic
7	Enable audit logging	You cannot investigate what you did not record	xpack.security.audit.enabled: true	Platinum
8	Patch and upgrade	EOL versions ship known, unpatched CVEs	Track release notes; upgrade off end-of-life majors	Basic
9	Field- & document-level security	Restrict rows/columns per role for multi-tenant data	Role field_security / query rules	Platinum

How do I check whether my cluster is already hardened?

Before changing anything, audit the current state. These read-only checks tell you if security is on, whether you are accidentally exposed, and which users and snapshots exist. Run them against your own endpoint and treat any unauthenticated 200 from a public address as an emergency.

# 1. Is security actually enabled? (should require auth; 401 without creds is GOOD)
curl -s https://localhost:9200/_xpack | jq '.features.security'

# 2. Confirm who you authenticate as (avoid running apps as this user if it's 'elastic')
curl -s -u elastic https://localhost:9200/_security/_authenticate | jq '.username, .roles'

# 3. List defined roles and users to spot over-privileged accounts
curl -s -u elastic https://localhost:9200/_security/role  | jq 'keys'
curl -s -u elastic https://localhost:9200/_security/user  | jq 'keys'

# 4. Do you have recent snapshots to restore from?
curl -s -u elastic https://localhost:9200/_snapshot/_all | jq 'keys'

# 5. RED FLAG: if this returns data from a PUBLIC IP with no credentials, you are exposed
curl -s http://<public-ip>:9200/_cat/indices

Which measures have the highest impact?

Network isolation and identity stop the breaches that actually happen. The overwhelming majority of Elasticsearch data leaks are not clever exploits — they are clusters bound to 0.0.0.0 on a public host with no authentication. So bind Elasticsearch to a private interface, firewall ports 9200 and 9300, and put a TLS-terminating reverse proxy in front only when external access is genuinely required. Then give every integration its own scoped API key — never the elastic superuser — so a leaked credential exposes one index pattern, not the whole cluster. The minimal hardened config below pairs a private bind with a default-deny firewall.

# config/elasticsearch.yml — minimal hardened baseline
cluster.name: prod-search          # unique name prevents stray nodes auto-joining
node.name: es-node-1
network.host: 10.0.1.10            # private interface ONLY — never 0.0.0.0 on a public host
http.port: 9200
xpack.security.enabled: true       # default-on in 8.x; set explicitly on 7.x
discovery.seed_hosts: ["10.0.1.10", "10.0.1.11"]
cluster.initial_master_nodes: ["es-node-1"]  # avoids split-brain on first formation

# Firewall: allow the private subnet, deny the world (Ubuntu ufw example)
sudo ufw allow from 10.0.0.0/16 to any port 9200 proto tcp
sudo ufw allow from 10.0.0.0/16 to any port 9300 proto tcp
sudo ufw deny 9200/tcp
sudo ufw deny 9300/tcp

How do I cover backups, auditing, and patching?

Authentication keeps attackers out; snapshots, audit logs, and patching let you recover and investigate when something still goes wrong. Automate snapshots with Snapshot Lifecycle Management (SLM) so you always have a clean restore point — essential against accidental deletes and ransomware. Enable audit logging (a Platinum feature) on regulated workloads so security events are recorded. And treat patching as a security control: running an end-of-life Elasticsearch major means shipping known, unpatched CVEs. The SLM policy below snapshots daily and retains 30 days.

# Register a snapshot repository (e.g. S3) then automate with SLM
curl -u elastic -X PUT "https://localhost:9200/_snapshot/backups" \
  -H 'Content-Type: application/json' -d '{
    "type": "s3",
    "settings": { "bucket": "my-es-snapshots", "region": "ap-south-1" }
  }'

# Snapshot Lifecycle Management: daily snapshot, keep 30 days / 30 snapshots
curl -u elastic -X PUT "https://localhost:9200/_slm/policy/daily-snapshots" \
  -H 'Content-Type: application/json' -d '{
    "schedule": "0 30 1 * * ?",
    "name": "<daily-{now/d}>",
    "repository": "backups",
    "config": { "indices": ["*"] },
    "retention": { "expire_after": "30d", "min_count": 7, "max_count": 30 }
  }'

What actually needs a paid licence?

Most of this checklist is free. Authentication, RBAC, TLS, the secrets keystore, snapshots, and SLM are all in the Basic (free) tier. Two controls require Platinum: field- and document-level security (per-row / per-column restrictions, useful for multi-tenant data) and audit logging. If you need those without an Elastic subscription, OpenSearch — AWS's fork created after Elastic's 2021 relicensing — ships the OpenSearch Security plugin with TLS, an internal user database, RBAC, and fine-grained access control at no cost (Elastic itself re-added an AGPLv3 open-source option in 2024). Whichever stack you run, the checklist above applies the same way. If you also parse logs through this cluster, the same hardening covers your ELK stack log pipeline and its Kibana and Beats layer.

Frequently Asked Questions

What is the single most important Elasticsearch security measure?

Never expose an unauthenticated cluster to the public internet. Enable the built-in security stack (on by default in ES 8.x), bind network.host to a private interface, and firewall ports 9200 and 9300. Public, credential-free Elasticsearch is the most common cause of real-world data breaches.

Which Elasticsearch security features require a paid licence?

Almost none of the essentials. Authentication, RBAC, TLS, the keystore, and snapshots are free in the Basic tier. Only field/document-level security and audit logging require a Platinum licence. OpenSearch provides comparable fine-grained access control for free.

How can I check whether my Elasticsearch cluster is already hardened?

Confirm requests without credentials are rejected (a 401 is good), verify xpack.security is enabled, list roles and users to find over-privileged accounts, and ensure recent snapshots exist. If a public IP returns index data with no authentication, treat it as an active incident.

Should my application connect as the elastic superuser?

No. The elastic account is for bootstrap and administration only. Create a least-privilege role scoped to the indices an app needs, then issue a dedicated API key. A leaked key then exposes one index pattern instead of the entire cluster.

What is the most common cause of Elasticsearch data breaches?

Misconfiguration, not exotic exploits — typically a cluster bound to 0.0.0.0 on a public host with security disabled or never enabled. Network isolation plus authentication eliminates the large majority of these incidents.

How often should I update Elasticsearch?

Treat patching as a security control: apply minor and patch releases promptly and never run an end-of-life major version, which ships known unpatched CVEs. Plan upgrades off EOL versions as part of routine maintenance, testing against a snapshot first.

Want this checklist applied to a production cluster — security enabled, network locked down, snapshots automated, and the version upgraded off end-of-life? MicroPyramid has secured and maintained Elasticsearch and OpenSearch clusters across 50+ projects since 2014. Explore our server maintenance services to keep your search infrastructure patched, encrypted, and breach-resistant.