OpenSearch vs Elasticsearch security features

OpenSearch security controls come with the source code. The OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch FAQ describes no paid edition, so the Security plugin's SAML, OpenID Connect, LDAP, document-level and field-level security and audit logs are not gated by a subscription tier. Elastic works differently. Its default distribution is under the Elastic License 2.0 (ELv2), with SSPL 1.0 and AGPLv3 as the other source options, and the security features an Elastic subscription gates are defined by tier, not by which license the code carries. An AGPLv3 build does not by itself unlock anything a subscription would otherwise restrict, so the license question and the entitlement question need separate answers.

Elastic's tier history shows why the entitlement question moves over time. In May 2019, with Elasticsearch 6.8.0 and 7.1.0, Elastic made TLS, the file and native user realms and role-based access control free in the Basic tier, while single sign-on, Active Directory and LDAP authentication and field- or document-level security stayed in paid tiers. Its current self-managed subscriptions page places the detection engine, machine learning anomaly detection and case management under Platinum, which is no longer sold to new customers, and endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise. A control that was free for one purchase may sit behind a different tier at renewal, so the feature list you audited last year may not be the one you buy today.

Before you commit, confirm the current edition terms directly with Elastic, including which tier covers each control your auditors will test, whether Platinum is available to you at all, and how the terms apply to your deployment model. Ask for the entitlement in writing and map each control to the document that proves it. Then check whether your audit scope depends on any Enterprise-only control, such as SSO, because that dependency will recur with every renewal. The Elastic subscriptions page is the starting point for that check, and your evidence should record the tier and version in force on the audit date.

The OpenSearch Security plugin gives you SAML, OpenID Connect, LDAP and Active Directory authentication, role-based access control, document-level and field-level security, field masking and audit logs without a paid tier. The license is free, but the design is not. Before go-live, decide how identity provider groups map to OpenSearch roles. Each SAML, OIDC or LDAP group needs a documented mapping to backend roles, and those roles need index patterns, document-level query filters and field-level rules that match your data classification. Test each mapping with a non-administrative account, because a mapping that grants too much access will not produce an error.

Audit logs need the same care. Decide which categories you record, where the records are written, who can read them and how long they are kept. Storing audit records in the same cluster they describe means an attacker who gains administrative access can also alter the trail, so plan a separate retention target and confirm with your compliance owner how long your frameworks expect records to be held. TLS needs a certificate plan too: node-to-node and client traffic each need certificates, with an issuing authority, a renewal process and a rotation runbook. Confirm the current configuration keys for your chosen version in the OpenSearch security documentation instead of copying settings from older blog posts.

Upgrades put all of this at risk. Security configuration files, role mappings and certificates must survive each minor release on the 3.x line, and 3.9.0 was released on September 29, 2026. OpenSearch versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and maintenance releases carry security patches but no new features. Build a schedule that moves you onto a supported line before end of maintenance, test the security configuration in a staging cluster first, and assign an owner for tracking each release.

Security configuration does not move with the data. Wire compatibility with Elasticsearch 7.10 and the supported path for indices from Elasticsearch 6.0 through 7.10, including rolling upgrades, cover the search and index layer. They do not carry over roles, users, realm mappings, document-level and field-level security rules, or audit settings. Role definitions, user-to-role mappings, and authentication realms (SAML, OIDC, LDAP or Active Directory) must be exported, translated into the target's model, and re-tested against real user groups. Confirm the export and mapping steps with the vendor and in a test cluster before committing to a migration window.

Audit logs and retention need their own validation. Audit records written by one security plugin are not guaranteed to match the field names, categories or retention behavior of the other. Downstream SIEM parsers, alert rules, and compliance evidence packs that depend on specific audit fields may break silently. Ask each vendor to document the audit event schema for the version you will run, then replay a known set of events (failed logins, role changes, document-level access denials) through both systems and compare the output. Confirm how long each platform keeps audit data by default and who owns that setting after the switch.

Plan the test window as a cost line. The main recurring cost is the people who verify access rules, not the software itself. Budget for a parallel environment, a checklist of every role and field-level rule, and sign-off from the data owners whose access may change. Ask for the migration and validation approach in writing, and confirm whether any paid tier is required to keep the same controls after the move. Commercial terms for each tier are listed on Elastic's subscriptions page, and the OpenSearch Security plugin documentation is at OpenSearch security.