When the free Elastic Security tier is enough and when Enterprise is needed
If your team runs Elastic Security on its own infrastructure, the free Basic tier covers log search and the core detection workflow, but it does not cover endpoint malware and ransomware prevention, host isolation or SAML and OpenID Connect single sign-on. Choose Basic when your detections are written and tuned in-house and your endpoint response is handled by other tooling. Choose Enterprise when prevention, containment from the Elastic console, or centralized identity is a requirement of your security or audit program. Platinum is no longer sold to new self-managed buyers, so the paid choice for a new deployment is Enterprise or Elastic Cloud.
Basic is a strong fit when the work is mostly search and investigation. Teams that ingest logs into Elasticsearch, build dashboards in Kibana, write their own correlation logic, and rely on TLS, native users and role-based access control can run a useful SIEM without a subscription. Basic also suits teams that already have a separate endpoint product. The trade-off is that the prebuilt detection content and Timeline workflow you see in the Elastic Security documentation still need the right tier for each feature, so confirm on the Elastic subscriptions page which detection and case features your version includes before you commit to a design.
Before you decide, list the controls you must demonstrate. If the answer includes isolating a compromised host from Kibana, blocking ransomware at the endpoint through Elastic Defend, or enforcing SSO for analysts, the requirement points to Enterprise. Ask Elastic or your reseller to confirm the current Enterprise price and term in writing, and ask DeployOpen to scope the integration work, including Fleet policy design and identity provider configuration, as a fixed-scope deliverable. Plan for the recurring subscription cost and for the one-time effort of migrating from Basic if you later need Enterprise features, since moving tiers changes what you deploy and how analysts sign in.
Which Elastic Security capabilities sit in each tier
This table maps the capabilities Elastic publishes for self-managed Basic, Platinum and Enterprise, so you can see where each feature sits before comparing costs. Read each row against the vendor's current subscriptions page, because tier placement is the vendor's to set and can change. The main takeaway is that Platinum is closed to new self-managed buyers, so new purchasers of paid security features are choosing between Basic and Enterprise.
| Capability | Basic (free and open) | Platinum | Enterprise |
|---|---|---|---|
| Detection engine and SIEM rules | Not applicable | Included | Confirm placement on the subscriptions page |
| Machine learning anomaly detection and alerting | Not applicable | Included | Included, confirm current placement |
| Case management | Not applicable | Included | Confirm placement on the subscriptions page |
| Endpoint malware and ransomware prevention | Not applicable | Not applicable | Included |
| Host isolation | Not applicable | Not applicable | Included |
| SAML or OpenID Connect single sign-on | Not applicable | Not applicable | Included |
| TLS, file and native user realms, role-based access control | Free since 2019 (Elasticsearch 6.8.0 and 7.1.0) | Included | Included |
| Field- and document-level security, FIPS 140-3 mode, encryption at rest | Confirm on the subscriptions page | Confirm on the subscriptions page | Confirm on the subscriptions page |
How licensing, support and updates differ across the three tiers
Free and open, Platinum and Enterprise share one codebase, but they differ in what the subscription adds, whether you can still buy it, and which release lines receive maintenance. Read each card with the vendor terms in hand, because the code license and the subscription terms are separate questions.
Basic: code license without a subscription
The default distribution of Elasticsearch and Kibana is licensed under the Elastic License 2.0, and the source is also offered under SSPL 1.0 and AGPLv3. Basic carries no vendor subscription terms to buy, so your obligations come from the license you accept and your own operating model. Confirm which license governs the exact build you deploy, and check whether ELv2 terms affect how you offer the stack to others.
AGPLv3 option for OSI-approved terms
AGPLv3 was added to the Elasticsearch and Kibana source before the 8.16 release, giving buyers an OSI-approved license option. Choosing it changes the legal terms you operate under, not the feature list you receive. If your policy requires OSI-approved licensing, confirm with legal which build and license your deployment uses, and confirm that your release line and any patches you apply stay within those terms.
Platinum: closed to new buyers
Platinum listed the detection engine, machine learning anomaly detection and case management. Elastic states it is no longer sold to new customers, so a new self-managed buyer cannot start on Platinum. If your plan depends on those features, confirm with Elastic which tier currently includes them, or whether Elastic Cloud is the route it directs new customers to, before you design around them.
Enterprise: terms confirmed in writing
Enterprise adds endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on. Support levels, response times, service commitments and renewal terms are set in your contract, not on the public page. Before purchase, request the support tier, SLA and upgrade assistance in writing, and confirm how the subscription applies to each node or host in your architecture.
Release lines in maintenance
Current Elasticsearch release lines are 9.5.5 and 9.4.8, released on October 6, 2026, and 8.19.23 is still maintained. End of maintenance for 8.x is January 15, 2027, and for the core 9.x line, October 15, 2027. Plan upgrades against these dates and ask Elastic which tier and release line your subscription covers during the transition.
Security patches across tiers
Maintenance of the release line determines whether you receive fixes, but support terms determine how quickly a vendor responds. Basic users depend on published releases and their own testing, while Enterprise buyers should confirm the patch delivery process, notification channel and emergency fix commitments in writing. Ask whether security fixes reach every supported line, including 8.19.23, or only the newest release.
What Platinum no longer being sold means for new buyers
New self-managed buyers have two paths for paid security features: Enterprise, or Elastic Cloud. Elastic's self-managed subscriptions page states that Platinum is no longer available to new customers and points them to Elastic Cloud instead. The features that used to sit in Platinum, including the detection engine, machine learning anomaly detection and case management, now reach self-managed buyers only through Enterprise, which also adds endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on. If you need those detections on your own infrastructure, budget for Enterprise from the start rather than planning around a tier you cannot buy.
If you already hold a Platinum subscription, confirm three things in writing with Elastic before your next renewal: whether renewal terms are still offered for your subscription, what upgrade path applies if you need Enterprise features, and which Elastic Stack versions your subscription covers. Use the Elastic end of life dates as a planning input. The 8.x line reaches end of maintenance on January 15, 2027, with 8.x support ending July 15, 2027, and the 9.x line reaches end of maintenance on October 15, 2027. A cluster you plan to run through 2027 will need an upgrade path that lands on a supported line, so schedule that work as part of the renewal decision rather than after it.
Before you purchase, check that every feature your detection program depends on is listed under the exact tier you will buy. Map each detection use case, anomaly-based alerting, case handling, single sign-on and endpoint response, to the subscription page, and note which ones are only in Enterprise. Alerting rules based on anomaly detection are limited to Platinum and Enterprise, so a Basic deployment cannot run them regardless of how much hardware it has. Ask Elastic or your reseller to confirm the tier mapping for your deployment model in writing, since the self-managed and cloud offerings differ in what they include and how they are licensed.
Which Elastic Security tier fits which team
A small security team that already writes and tunes its own detection content often needs less from a paid tier than its buyers expect. The core detection work, including rule authoring, Timeline investigations and the detection engine's correlation, indicator match and threshold rules, sits in the detection capabilities that Elastic lists on its subscriptions page. The team should confirm which of those capabilities it needs in the Basic tier it would run, because the paid split is not the same as a simple on or off switch for every SIEM feature.
- Detection authoring: Teams that write correlation, threshold or indicator match rules and maintain them in Kibana should check that their rule set works in the tier they plan to run.
- Prebuilt rules: Elastic develops prebuilt rules in the elastic/detection-rules repository under the Elastic License v2, which is useful to read even when the team runs Basic.
- Anomaly detection: Machine learning anomaly detection and its alerting rules are listed under Platinum and Enterprise, so a team that depends on them must budget for a paid tier.
- Case management: Cases were part of the Platinum bundle, so a small team that relies on them for handoffs needs to confirm the current tier placement.
- Basic is the better choice when: the team builds and maintains its own rules, does not need endpoint prevention, host isolation or single sign-on, and has no requirement for anomaly alerting.
Before committing, confirm the exact tier placement of each feature with Elastic's current subscriptions page and your own test cluster.
A regulated enterprise usually needs controls that go beyond detection. Endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on are listed under the Enterprise tier on Elastic's self-managed subscriptions page. Auditors and internal risk teams often ask for central identity, documented containment steps and demonstrable prevention on endpoints, so the Enterprise tier is the one this team should evaluate first. Compliance assessors decide what evidence is sufficient, and DeployOpen prepares controls and evidence without issuing attestations.
- Endpoint prevention: Malware and ransomware prevention and memory threat protection are Enterprise capabilities that should be tested against your own host builds.
- Host isolation: Confirm how isolation is authorized, logged and reversed in your change process before you rely on it.
- Single sign-on: SAML and OpenID Connect are Enterprise features, so the identity provider integration is part of the licensing decision.
- Access control details: Field- and document-level security and attribute-based access control are listed among the security features, and their tier placement should be confirmed for your edition.
- Basic is still the choice when: the regulator or internal policy accepts local accounts and detection-only monitoring, with endpoint prevention handled by another product.
Ask Elastic for written confirmation of which Enterprise features apply to your deployment model before you match them to your control catalog.
A team that already holds a Platinum subscription is in a different position from a new buyer. Elastic's subscriptions page states that Platinum is no longer available to new customers, so renewal and expansion are the questions that matter. Platinum covers the detection engine, machine learning anomaly detection and case management. The team should not assume that renewing Platinum is the same as buying a current tier for a new deployment, and it should confirm the terms of its existing agreement with Elastic.
- Renewal terms: Confirm with Elastic how the existing subscription renews, what it covers, and whether it changes at the next term.
- Feature gap: Endpoint prevention, host isolation and single sign-on are not part of Platinum, so teams that need them must plan a move to Enterprise.
- Version support: Elastic lists end of maintenance dates for the 8.x and 9.x lines, so check which version your cluster runs before planning upgrades.
- Migration path: Moving to Enterprise or to Elastic Cloud changes the licensing and operating model, so the effort should be estimated in your own environment.
- Basic is the better choice when: the existing Platinum features are no longer used, and the team plans to drop anomaly detection and case management, though it should still confirm what the current terms require.
Request a written statement of the renewal and migration options from Elastic before you schedule any change.
What each Elastic Security edition costs to own
This table breaks down the cost components of running self-managed Elastic Security on the Basic, Platinum and Enterprise tiers, separating what is paid to Elastic from what your own team and infrastructure absorb. Read it as a checklist: the license row is the only one with a fixed vendor price question, and the rest recur with data volume and team size.
| Cost component | Basic (free and open) | Platinum (no longer sold to new customers) | Enterprise |
|---|---|---|---|
| Software license or subscription | No license fee. Basic is the free tier of the self-managed subscription page. | Not available to new self-managed customers, per Elastic's subscriptions page. Existing subscribers should confirm renewal terms in writing. | Paid subscription. Elastic's subscriptions page publishes no price in our sources, so request a written quote. |
| Infrastructure for Elasticsearch and Kibana nodes | Recurring. You size and pay for data, ingest, master and Kibana nodes in your own cloud or data center. | Recurring, same node sizing as Basic. Any tier change does not reduce hardware needs. | Recurring, same node sizing as Basic. Highly available clusters need at least three master-eligible nodes. |
| Storage and retention | Recurring. Hot, warm, cold and frozen tiers are your decision, and each adds disk and retention cost. | Recurring. Retention policy and tiering drive storage spend the same way as on Basic. | Recurring. Endpoint and prevention telemetry can add volume, so confirm data volume assumptions before quoting. |
| Staff time for upgrades and patching | Recurring. Your team handles version moves; Elastic's EOL page lists 8.x end of maintenance on January 15, 2027 and 9.x on October 15, 2027. | Recurring, with the same upgrade work. Plan for a version path, since Platinum is not a new purchase. | Recurring. Support scope for upgrades should be written into the quote, not assumed. |
| Detection rule tuning and content work | Recurring. Prebuilt rules come from the detection-rules repository, but tuning false positives is staff work. | Recurring. Detection engine, anomaly detection and cases are included, but rule tuning is still your team's effort. | Recurring. Endpoint prevention, host isolation and SSO add policy work for administrators. |
| Identity and SSO integration | Recurring effort only. Native users, roles and TLS are free, but SSO is not included. | Recurring effort only. SSO remains outside Platinum's feature set. | Included as a feature (SAML or OpenID Connect). Integration with your identity provider is still one-time setup plus ongoing maintenance. |
| Implementation services | One-time if you engage a partner. Scope, deliverables and timelines are agreed in writing before work starts. | One-time if you engage a partner. Confirm whether existing Platinum deployments need re-scoping. | One-time, plus any retainer for ongoing support. Request separate line items for implementation and retainer. |
| What to request in a written quote | Node count and sizing basis, storage tiers and retention period, upgrade cadence, and the staff hours you expect your team to commit. | Confirm current subscription status, renewal terms and whether your tier maps to Enterprise features at renewal. | Subscription price with term length, support scope, included features list, and any separate implementation or retainer fees. |
Moving from Basic to Enterprise without rebuilding the stack
A team already running self-managed Basic can add Enterprise features to the same cluster by changing the license, enabling features and validating them before rollout, without rebuilding indexes or re-onboarding data.
Confirm the target version on a supported release line
The platform engineering lead checks the current Elastic Stack version against Elastic's support lifecycle before any change. Elastic's end-of-life page lists the 9.x core stack end of maintenance on October 15, 2027, and the 8.x line on January 15, 2027, with 8.x support ending July 15, 2027, so an 8.x cluster may need an upgrade path first. Done means the target version is written down and every node runs a release that Elastic still maintains. Confirm the exact upgrade path in Elastic's current documentation, since the sequence depends on the starting version.
Back up cluster state and configuration
The cluster administrator takes a snapshot of indices and cluster state to a repository outside the cluster, then copies Elasticsearch and Kibana configuration files, role and realm settings, and Elastic Agent policies exported from Fleet. Done means a restore has been tested on a separate cluster and the team can point to the snapshot ID and the configuration copies. Ask Elastic which backup steps apply to your deployment model before relying on this.
Apply the Enterprise license to the existing cluster
The administrator applies an Enterprise subscription license to the running cluster through the license management interface or API, following Elastic's current licensing instructions. Existing indices, data streams and detection rules stay in place because the change is to the license, not to the storage layout. Done means the cluster reports the Enterprise license type on every node, and Kibana shows the security features that were previously unavailable. Confirm license activation steps and any node restart requirements with Elastic before the change window.
Enable Enterprise features and configure realms
The security engineer turns on SAML or OpenID Connect single sign-on realms, maps identity provider groups to Kibana and Elasticsearch roles, and creates Elastic Defend policies with malware and ransomware prevention and host isolation enabled where the team has decided to use them. Role mapping is where most access mistakes happen, so this step needs someone who knows both the identity provider and Elastic roles. Done means a test user from each identity group signs in and sees only the expected spaces and alerts.
Validate prevention policies in a non-production cluster
The detection engineer repeats the license change, realm configuration and endpoint policies on a non-production cluster with a copy of the production configuration. Test prevention policies on a small set of lab endpoints, confirm that expected detections fire, and confirm that host isolation can be released by an authorized analyst. Done means a written test record lists each policy, the endpoints tested, the result and any exceptions added. Policy behavior depends on the Elastic Defend version, so check the release notes for the version you run.
Roll out in stages and monitor the results
The team applies the validated policies to production endpoints in groups, starting with lower-risk hosts, and watches alert volume, agent health and user sign-in failures after each group. Rollback means reverting the policy assignment in Fleet, which is different from removing the license. Done means every group reports healthy agents and the security operations lead accepts the alert baseline. Keep the validation record and change log, since auditors and internal reviewers often ask for both.
Plan the license lapse path before it is needed
The buyer and the platform owner document what happens if the Enterprise subscription expires or is not renewed. Elastic's subscription terms and license documentation govern whether features stop, degrade or remain available, so get that answer in writing from Elastic before go-live. Ask whether existing policies keep enforcing, whether SSO sign-in continues, and what the fallback access path is for administrators. Done means the lapse behavior is recorded, a named owner tracks renewal dates, and the team knows which controls to replace if the license is not renewed.
Where the free tier falls short for typical enterprise controls
The gaps a regulated enterprise usually hits on Basic are the Enterprise-tier controls: endpoint malware and ransomware prevention, host isolation, and SAML or OpenID Connect single sign-on. Elastic's self-managed subscription page places these under Enterprise, so a self-managed deployment on Basic does not include them. If your endpoint policy depends on Elastic Defend blocking malware or isolating a compromised host, or your identity policy requires federated sign-on to Kibana, Basic will not meet that requirement and you will need Enterprise or another control.
Basic is still useful for several enterprise needs. It covers log search, TLS, the file and native user realms, and role-based access control, which many teams use to separate analyst and administrator duties. You can also write and run your own detections. Some teams close the endpoint or identity gaps with tools they already run, such as an existing EDR or identity provider, and keep Basic for log retention and search. That approach only works if those tools produce the evidence your auditors expect in Elastic, so confirm the integration path before you rely on it.
Field- and document-level security, attribute-based access control, and encryption at rest support are also listed on Elastic's subscription page as security features, and the page indicates which of them sit outside Basic. Do not assume they are available because TLS and RBAC are free. Build a control matrix that maps each requirement from your own security policy and compliance obligations to a specific Elastic feature, its tier, and the evidence it produces. Ask Elastic or your reseller to confirm tier placement for each line in writing, and check the current subscriptions page before procurement, because tier boundaries have changed over time.
What buyers ask about Elastic Security editions, effort and services
Is the free Basic tier enough to run a SOC on Elastic Security?
Basic can support some SOC work, but it does not include the detection engine, machine learning anomaly detection or case management, which sit in Platinum, and endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on, which sit in Enterprise. Confirm which of those capabilities your analysts need on day one. If your detections depend on the detection engine or on isolating a compromised host, Basic alone will not cover that workflow. Map each analyst task to a tier on Elastic's subscriptions page before you decide.
What does Enterprise add over Platinum, and what will it cost?
Elastic's self-managed subscription page lists endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise, so those are the features you would be paying for beyond the Platinum set. No price list was supplied for this comparison, so the cost must come from a written quote from Elastic or its reseller. Ask for the subscription price per tier, the node or RAM basis it is calculated on, whether it renews annually, and what support is included. Your cost also depends on cluster size, data volume and how many endpoints you cover, and DeployOpen's fee is set separately in a written scope.
Can I still buy Platinum as a new self-managed customer?
No. Elastic's self-managed subscriptions page states that Platinum is no longer available to new customers, who are pointed to Elastic Cloud instead. A new self-managed buyer who needs paid security features therefore chooses between Basic and Enterprise, or moves to Elastic Cloud. Confirm the current position with Elastic before you write a requirement that names Platinum, because the outline you hand to procurement should describe the features you need rather than the tier name.
Should Platinum customers renew now or move to Enterprise?
Renewal depends on whether you use the Platinum features today and whether you need Enterprise features later. Ask Elastic what renewal terms and tier mappings apply to an existing Platinum subscription, and whether the features you rely on are still covered. Also check the support window for your version: Elastic lists end of maintenance for the 8.x line on January 15, 2027, with 8.x support ending July 15, 2027, and 9.x maintenance ending October 15, 2027. A version move and a tier move are separate decisions, so plan them in one written schedule to avoid two disruptive changes.
How long does an edition move take?
The duration depends on cluster size, the number of nodes and data tiers, the number of agents and policies to migrate, and how much testing your detections need before cutover. It is not a figure this comparison can give. DeployOpen sets the timeline in a written plan that is agreed before work starts, and the plan lists the phases, dependencies and acceptance checks. Ask for the plan to show which work runs in parallel with your current alerting, and how rollback works if a detection regresses.
Can my team manage the cluster and policy work without outside help?
A team can do it alone if it already runs Elasticsearch in production and has people who understand node roles, index lifecycle, certificates, role-based access control and Elastic Agent policies. Elasticsearch's node roles documentation notes that a highly available cluster needs at least three master-eligible nodes, so cluster design is a real skill gap for teams that have only run a single node. Assess your team against that list, and where gaps exist, ask for a scoped knowledge transfer alongside the migration.
What does the work need from our side?
You will need named owners for infrastructure, identity, detection content and incident response, plus access to the target hosts, network paths, certificate authorities and a test window. Identity work depends on your directory and whether SSO is in scope, so identity administrators must be available. Ask DeployOpen to list these inputs in the written scope, with the person or role responsible for each, so the schedule does not depend on informal availability.
How DeployOpen scopes and delivers either Elastic Security edition
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, so Elastic Security can run on your cloud accounts, data centers or air-gapped networks. The work starts from a written scope that names the edition, the detections and the identity model you need before any build begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the Elastic Security tier, whether that is Basic or Enterprise, and which features it depends on.
- Scope records which log sources, endpoints and detection use cases must be onboarded, and which are out of scope.
How we build
- Deployment covers the Elasticsearch and Kibana cluster, Elastic Agent enrollment and Elastic Defend policies within your environment.
- Node roles, hot, warm and cold storage tiers and sizing are set against the retention and ingest targets in the scope.
- Identity integration, role-based access and detection rule configuration are tested against the agreed use cases before handover.
How we hand over
- Handover includes configuration documentation, runbooks for upgrades and a record of which features each tier provides.
- Evidence for compliance assessments is prepared, while independent auditors and certification bodies issue any reports.
- Your team receives a written list of licensing conditions, so future tier changes are planned against known capabilities.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
- Retainer scope should state which Elastic release lines are covered and who applies patches and version upgrades.
- Ask your quote to separate one-time build work from recurring support, so the cost of each stays visible.
