Elastic Security or OpenSearch Security Analytics: which fits your SOC
If your regulated team is choosing a self-hosted SIEM layer, the decision is really about where detection content comes from and who maintains it. Elastic Security fits teams that want packaged detections, the Timeline investigation view, Cases and Elastic Defend endpoint protection in one product, and that can accept Elastic License 2.0 terms and plan around tier gating. Elastic's detection rules are developed in the elastic/detection-rules repository and delivered automatically to the Kibana detection engine, so the prebuilt library arrives with the product. The trade-off is that several capabilities sit behind paid self-managed tiers, and Platinum is no longer sold to new customers, so a self-managed buyer should expect to choose between the free Basic tier and Enterprise, or move to Elastic Cloud.
OpenSearch Security Analytics fits teams that need Apache-2.0 licensing end to end and that have, or will build, the capacity to own detection content. It matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types, so no separate SIEM product is required. Sigma rules are portable across tools, which helps if you already maintain detection logic outside one vendor. The cost is that you own the rule lifecycle: selecting rules, tuning them, testing them against your log sources and documenting coverage for auditors. Confirm in the OpenSearch Security Analytics documentation which prepackaged rules and correlation types you need before you commit.
Which platform fits which scenario
This table maps common team situations to the platform that fits better and the condition that decides it. Read each row as a starting point, then confirm the licensing and feature details against current vendor documentation before you commit.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Endpoint-heavy enterprise needing malware and ransomware prevention and host isolation | Elastic Security | Those endpoint protection features sit in Elastic's Enterprise tier on self-managed deployments, so budget for that subscription or confirm the Elastic Cloud option. |
| Team that must use only an OSI-approved license for policy reasons | OpenSearch Security Analytics | OpenSearch is Apache-2.0 across the project, while Elastic's default distribution is ELv2, which is not OSI approved, so check whether AGPLv3 Elastic builds meet your policy. |
| Organization that already runs an OpenSearch cluster for logs | OpenSearch Security Analytics | Adding Security Analytics to an existing cluster avoids a second search engine, but your team must own Sigma rule curation and correlation tuning. |
| Small team that wants prebuilt detection content out of the box | Elastic Security | Elastic delivers its latest prebuilt rules to the Kibana detection engine automatically, which reduces rule authoring, but confirm which rules your tier can run. |
| Air-gapped environment with no outbound access to vendor content feeds | Depends on rule update process | Both need offline rule and package staging, so test how each platform's rule updates are mirrored into the enclave before choosing. |
| Organization planning to customize detections with Sigma rules from its own library | OpenSearch Security Analytics | Sigma is the native rule format in Security Analytics, so existing Sigma content maps more directly than Elastic's detection rule format. |
| Team that expects to self-host long term with a clear support window | Confirm with each vendor | Elastic lists end of maintenance dates for its 8.x and 9.x lines, while OpenSearch maintenance follows its own version policy, so compare the lines you would deploy. |
How each stack is built and what that means for operations
Both platforms sit on the Elasticsearch lineage, but they package the SIEM layer differently. The cards below cover what each stack includes, what you must assemble yourself, and how the choice shapes upgrades and maintenance windows.
Elastic Security as a bundled stack
Elastic Security runs on Elasticsearch and Kibana, with Elastic Agent collecting logs and running Elastic Defend under central management in Fleet. The detection engine, Timeline and Cases ship in the Kibana application, so you deploy one vendor stack rather than assembling parts. Check which agent mode and Fleet Server layout your hosts need, especially for locked-down or air-gapped networks.
Node roles and the three-node minimum
Elasticsearch separates master-eligible, data (with hot, warm, cold and frozen tiers), ingest and coordinating roles. A highly available cluster needs at least three master-eligible nodes, so plan that quorum into the first design, not as a later addition. Ask which tier layout and retention split your log volume requires before sizing hardware.
Security Analytics on OpenSearch and Dashboards
Security Analytics runs as a feature on OpenSearch and OpenSearch Dashboards, so the SIEM layer and the search engine share one codebase and one upgrade path. Log types, detectors and findings are configured in the Dashboards interface. Confirm that your OpenSearch version includes the Security Analytics plugin features you need before committing to a line.
Sigma rules and cross-log correlation
Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings, and correlates them across log types. Your team owns the rule lifecycle: tuning, testing against your sources, and deciding which detections to promote. Ask how many prepackaged rules cover your log sources and who maintains the custom Sigma library after launch.
What you build around OpenSearch
Security Analytics does not supply the endpoint agent, case workflow, or response console on its own. You will need to choose and run log shippers, endpoint telemetry, alert routing, case handling and access control for analysts. Map each missing piece to an owner before you choose OpenSearch, because these integrations are the main operating effort.
Upgrade cadence and maintenance windows
OpenSearch targets a new minor version about every eight weeks, and each version gets bug fixes and security patches but no new features during maintenance. Elastic publishes its own release lines with different end-of-maintenance dates, so the two stacks will not move in step. Build the upgrade calendar for both engines, and confirm the support window for the exact version you deploy.
Detection, investigation and access features side by side
This table maps the detection, investigation and access capabilities of Elastic Security against OpenSearch Security Analytics and its Security plugin. Read each row for the tier or edition it sits in, then confirm the feature against the current vendor documentation and a test cluster before you commit.
| Capability | Elastic Security | OpenSearch Security Analytics |
|---|---|---|
| Detection rule types | Correlation, indicator match and threshold rules in the detection engine, per Elastic's subscriptions page | Sigma rules matched against ingested logs, with findings recorded and correlated across log types, per the OpenSearch documentation |
| Prebuilt rules | Prebuilt rules under ELv2, delivered automatically to the Kibana detection engine; customization is listed on the subscriptions page | Prepackaged Sigma rules plus custom Sigma rules; confirm coverage for your log sources |
| Alert suppression and tuning | Alert suppression is listed among Elastic Security capabilities; confirm the tier in your subscription | Tuning depends on your own Sigma rule set and correlation logic; confirm the workflow you need |
| Timeline and Cases | Timeline for investigations and Cases for case management; case management sits under Platinum, which is no longer sold to new customers | Not described in the supplied OpenSearch documentation; confirm whether you need a built-in case workflow or an external one |
| Entity analytics and ML anomaly detection | Entity analytics and machine learning anomaly detection are available; anomaly-based alerting rules are limited to Platinum and Enterprise | Not described in the supplied material; confirm any anomaly or entity capability with the vendor |
| Attack Discovery | Listed on Elastic's subscriptions page as an Elastic Security capability; confirm its tier and data requirements | Not described in the supplied material |
| Endpoint prevention and host isolation | Malware and ransomware prevention, memory threat protection and host isolation are Enterprise features, delivered through Elastic Defend | No endpoint agent or host isolation described; OpenSearch covers the search and analytics layer, so plan a separate endpoint tool |
| SSO protocols | SAML and OpenID Connect single sign-on are under Enterprise on the self-managed page | SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JWT authentication backends in the Security plugin |
| RBAC | Role-based access control was made free in the Basic tier with Elasticsearch 6.8.0 and 7.1.0 | Role-based access control is part of the Security plugin; confirm role mapping against your identity source |
| Field and document-level security | Field- and document-level security are listed among paid security features on the self-managed page | Document-level and field-level security, plus field masking, are provided by the Security plugin |
| Audit logs | Confirm audit logging and its tier for your self-managed deployment in the subscription terms | Audit logs are included in the Security plugin; confirm retention and export with your own test |
| FIPS mode | FIPS 140-3 mode is listed among security features on the self-managed page; confirm the build and tier you need | Not described in the supplied OpenSearch material; ask the vendor or your assessor before relying on it |
Licensing and editions: what Elastic gates and what OpenSearch leaves open
Elastic's default distribution of Elasticsearch and Kibana is under the Elastic License 2.0 (ELv2). The same source code is also offered under SSPL 1.0 and AGPLv3. Elastic says it added AGPLv3 to offer an OSI-approved open source option, and it states that ELv2 and SSPL are not OSI-approved. The license governs the software you run, so a team with an open source procurement rule should confirm which option its policy accepts. Rule content follows a separate license.
- Default distribution: ELv2 applies unless you select one of the other offered licenses for the software.
- AGPLv3 option: added in September 2024, before the 8.16 release, and offered as the OSI-approved choice.
- SSPL 1.0 option: offered for the source code, but not OSI-approved.
- Detection rules: developed in the elastic/detection-rules repository under ELv2, with the latest prebuilt rules delivered to the Kibana detection engine automatically. Check whether your policy allows you to copy, modify and redistribute those rules.
- Scope check: ask Elastic which license covers each package and feature in your deployment.
Confirm with Elastic in writing which license terms apply to the exact packages, features and rule content in your scope.
Elastic's self-managed subscriptions page offers a free and open Basic tier, plus Enterprise. Elastic's 2019 announcement moved TLS, the file and native user realms and role-based access control into the free tier, while single sign-on, Active Directory and LDAP authentication, and field- and document-level security stayed in paid tiers. The current subscriptions page lists SAML, OpenID Connect, Kerberos and JWT single sign-on, attribute-based access control, field- and document-level security, encryption at rest and FIPS 140-3 mode among security features, without giving the tier for each in the material supplied for this page.
- Basic: free for self-managed use, with TLS, file and native realms and role-based access control, based on the 2019 announcement.
- Enterprise single sign-on: SAML and OpenID Connect sign-on are listed under Enterprise.
- Endpoint controls: endpoint malware and ransomware prevention and host isolation are listed under Enterprise.
- Field and document-level security: paid in 2019, so confirm the current tier before you assume it is free.
- Encryption at rest and FIPS mode: listed on the subscriptions page, so confirm the tier for your version.
Ask Elastic for a tier matrix that maps each control in your control matrix to Basic, Enterprise or Elastic Cloud.
Elastic's subscriptions page lists the detection engine, machine learning anomaly detection and case management under Platinum. The same page states that Platinum is no longer sold to new customers and points new buyers to Elastic Cloud. For a self-managed deployment, that leaves Basic and Enterprise as the choices, and any feature the page places only under Platinum needs a written answer before you rely on it.
- Detection engine and Cases: listed under Platinum, so new self-managed buyers should confirm where these sit under current terms.
- Anomaly-based alerting: the subscriptions page says alerting rules based on anomaly detection are only on Platinum and Enterprise.
- Enterprise coverage: the supplied material does not confirm that Enterprise includes the detection engine, anomaly alerting or Cases, so ask Elastic directly.
- Existing agreements: if your organization already holds a Platinum subscription, ask how renewals, support and upgrades are handled.
- Support windows: Elastic lists end of maintenance for 8.x on January 15, 2027, and for the 9.x core stack on October 15, 2027, which affects your upgrade plan.
Confirm with Elastic in writing which tier includes each detection and case feature you plan to use, and how that position may change before your go-live date.
All software in the OpenSearch project is released under the Apache License, Version 2.0. The OpenSearch FAQ does not describe any paid edition. The OpenSearch Software Foundation is a Linux Foundation project, but it does not oversee the technical direction of the project. Security Analytics matches logs against prepackaged or custom Sigma rules, records findings and correlates them, and the Security plugin provides access control and audit features under the same license.
- Project license: Apache-2.0 for the project software, with no edition split described in the FAQ.
- Security plugin: role-based access control, document- and field-level security, field masking, audit logs, TLS and SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JWT authentication backends are documented.
- Detection content: Sigma rules are prepackaged or custom, so you own tuning and the license of any third-party rule set you adopt.
- Maintenance: during maintenance, a version receives bug fixes and security patches but no new features, so plan upgrades around that window.
- Commercial support: any paid support or add-on comes from a vendor, not from the project, so ask that vendor for its own terms.
Confirm with OpenSearch and any support provider which Security Analytics and Security plugin features apply to your release and whether any are offered commercially.
What drives running cost on each side
Running cost on either platform is set by a handful of decisions made early: how many nodes you run, which license tier you need for the detections you rely on, and who writes and tunes the rules. The cards below separate one-time build work from the recurring operating load, so you can ask vendors and partners for quotes that show both.
Node count, RAM and storage sizing
Elasticsearch node roles include master-eligible, data (with hot, warm, cold and frozen tiers), ingest and coordinating-only nodes, and a highly available cluster needs at least three master-eligible nodes. OpenSearch clusters follow the same planning logic, so the sizing question is similar on both sides. Ask each side for a sizing model based on your daily ingest, retention period and replica count, and check whether the quote covers the three master-eligible nodes and the storage tiers you plan to use.
Licensing tier spend
Elastic Security detections, case management and endpoint prevention sit in paid self-managed tiers, and Platinum is no longer sold to new customers, so a new buyer chooses between Basic and Enterprise or moves to Elastic Cloud. OpenSearch Security Analytics is under Apache-2.0 and the OpenSearch FAQ does not describe a paid edition, so license spend on that side is typically limited to whatever you add around it. Confirm with Elastic which features your detection set needs and get that tier priced in writing.
Staff time to write and tune rules
Elastic ships prebuilt detection rules that are delivered to the Kibana detection engine automatically, which reduces the authoring work on that side. On OpenSearch Security Analytics, you match logs against prepackaged or custom Sigma rules and build correlations yourself, so rule writing, false-positive tuning and rule review are recurring engineering hours. Ask any partner to estimate these hours against your log sources and to show who owns rule changes after handover.
Support and maintenance options
Elastic support is tied to the subscription tier you buy, while OpenSearch support comes from the community, from the vendors and service firms that offer it, or from a retainer agreed with an implementer. Support scope changes the cost of a bad week more than the license line does, so ask what response commitments are included, who answers for the search cluster and who answers for the detection content. Any SLA must be written into the quote, not assumed.
Upgrade effort across release lines
Elastic maintains each major release for the longer of 30 months from general availability or 18 months after the next major release, plus 6 more months of support, and lists end of maintenance for the 8.x line on January 15, 2027 and for 9.x on October 15, 2027. OpenSearch targets a new minor about every eight weeks, and each version stays in maintenance until the next major enters maintenance or one year passes, whichever is longer. Budget for regular upgrades on either side, and ask which release line each quote assumes and how many upgrade cycles it covers.
One-time build versus recurring operations
The build covers architecture, ingest pipelines, parsers, detection content, dashboards, access controls and hardening, and is usually a fixed piece of work. Operations cover node health, index lifecycle, patching, rule tuning, backup checks and evidence for audits, and they recur every month for as long as the system runs. Ask quotes to split these two lines, and to state which upgrades, rule updates and backup tests are included after go-live and which are billed separately.
What OpenSearch Security Analytics leaves to your team
On OpenSearch, Security Analytics gives you the matching engine, but the SIEM operating model is yours to assemble. The first job is rule selection and tuning. Security Analytics matches ingested logs against prepackaged or custom Sigma rules, so your team decides which rule sets are enabled per log type, which are disabled because they are noisy in your environment, and which custom Sigma rules cover your own applications. Confirm in the current Security Analytics documentation which prepackaged content ships for each log source you collect, and record every tuning decision with a reason so that a later reviewer can trace why a finding fired or stayed silent. Compare that workload with Elastic's detection engine, where prebuilt rules are delivered to the Kibana detection engine automatically and customization is an option, not a prerequisite.
Second, the case and investigation workflow and endpoint telemetry are gaps you must fill. Security Analytics records findings and correlates them across log types, but it does not give you the analyst workflow that Elastic provides through Timeline and Cases. You will need to define triage ownership, escalation paths, retention for evidence, and the ticketing or case tool that analysts use, then integrate it with OpenSearch Dashboards. On the telemetry side, you must select and deploy the agents or shippers that feed host logs, file integrity data and process events, and confirm how each one is managed across Linux, Windows and macOS. Elastic Defend and Elastic Agent are managed centrally through Fleet, whereas on OpenSearch the collection layer and its configuration lifecycle belong to your team.
The trade-off is clear. Without a paid tier, the license cost is zero, you keep full control of rules, data flow and retention, and you avoid vendor-driven feature gating. That advantage holds when you have detection engineers who can write, test and version Sigma content and when your SOC already runs its own investigation tooling. It becomes a burden when the team is small and nobody owns rule quality, because unmaintained rules create alert fatigue and blind spots that go unnoticed until an incident exposes them. Ask any implementation partner to quote the detection content, tuning cycles, case tooling and telemetry work as separate line items, and confirm your staffing for each before you choose the path.
Moving between Elastic Security and OpenSearch Security Analytics
This sequence shows how a team inventories its detections and log sources, decides which rules and dashboards can move, migrates indices and identity mappings, and retires the old stack without losing detection coverage. Each step ends with a check you can verify before moving on.
Inventory detections, log sources and dependencies
The security engineering lead, with the SOC team, lists every log source feeding Elastic Security (Elastic Agent policies, Beats, Logstash pipelines, syslog and API collectors) and every active detection rule, case workflow, Timeline saved search and automated response. Record which rules are prebuilt Elastic rules, which are custom, and which depend on Elastic-only features such as machine learning anomaly detection, Attack Discovery, or host isolation, since those need a paid Elastic tier to run today. Confirm the Elastic subscription tier in use before this step, because the features depending on it determine what you must rebuild. The step is done when you have a signed-off inventory with one owner per log source and one owner per detection.
Classify which rules and dashboards transfer
The detection engineering team sorts each item into one of three groups: rules that can be expressed as Sigma rules and loaded into OpenSearch Security Analytics, rules that depend on Elastic's query language, EQL or detection engine features and must be rewritten, and dashboards or Kibana saved objects that need to be rebuilt in OpenSearch Dashboards. Elastic's detection rules are licensed under the Elastic License v2 in the elastic/detection-rules repository, so review the license terms before copying any rule text into another product and treat the logic as a starting point to rewrite. Confirm each rule's field mappings against the log schema the OpenSearch side will receive. The output is a transfer matrix that labels every rule as move, rewrite or retire, with a named reviewer for each rewrite.
Plan the index and data migration path
The platform engineering team decides whether historical data moves or stays in place for its retention window. OpenSearch is wire-compatible with Elasticsearch 7.10 and can use indices created from Elasticsearch 6.0 through 7.10, and it supports rolling upgrades from those versions. Anything created on newer Elastic 8.x or 9.x releases falls outside that compatibility range, so those indices cannot be read directly and need reindexing or export through a supported tool, such as a pipeline that re-ingests from the source. Confirm the exact versions of your source cluster and the OpenSearch target against the OpenSearch migration documentation before choosing a path. The output is a written migration plan that states, per index family, whether data is migrated, re-ingested or left to expire.
Map identity, roles and access controls
The identity team and the SOC lead rebuild access rules in the OpenSearch Security plugin rather than copying Elastic role definitions. Map each Elastic role and space to an OpenSearch role, then define index permissions, document-level and field-level security, and field masking where your analysts need restricted views. Connect the identity provider using the SAML, OpenID Connect, LDAP or Active Directory backend that your directory supports, and confirm group-to-role mapping with test accounts from each analyst tier. Audit logging and TLS for node and client traffic must be configured again on the new cluster. The step is done when a test account from each role can perform its required searches and cannot reach data outside its scope.
Stand up the OpenSearch stack and load content
The platform team installs the OpenSearch cluster using the method your standards allow, such as the Docker, Helm, tarball, RPM or Debian packages documented by OpenSearch, and deploys OpenSearch Dashboards alongside it. The detection engineering team then loads the Sigma rules from the transfer matrix into Security Analytics, verifies that prepackaged content covers the log types in scope, and configures correlation rules for the cross-source detections that the Elastic version relied on. Rewritten detections are tested against replayed or sample events, not just deployed. The output is a test report showing each migrated detection fired on its expected test event and each correlation produced the expected finding.
Run both stacks in parallel
The SOC runs Elastic Security and the OpenSearch build side by side, with the same log sources feeding both where your collectors allow it. Compare alert volume, alert fidelity and triage time per detection, and check that every alert from the Elastic baseline has an equivalent or a documented reason for absence on the OpenSearch side. Document any gaps in coverage, false positive differences and missing response actions, such as host isolation or endpoint prevention, which the OpenSearch path must cover through other tooling or accept as a risk. The step is done when the detection owners sign off on each rule's parity result, and the risk owner accepts any remaining gaps in writing.
Cut over and retire the Elastic stack
The CISO or SOC manager approves the cutover date after parallel run sign-off. Point collectors, Elastic Agent policies and alert forwarding at the OpenSearch endpoints, update the on-call runbooks, and keep the Elastic cluster read-only for a retention period set by your records policy. Export any cases, notes and audit trails that must survive decommissioning, and confirm the export is readable before shutdown. Once the record-keeping window closes, remove Elastic nodes, revoke service accounts and rotate any secrets they used. The output is a decommissioning record listing what was exported, where it is stored and who approved deletion.
Document what was rebuilt rather than carried over
The compliance lead and detection engineers record which items did not transfer as-is. Expect Elastic-specific artifacts such as Kibana saved objects, detection rule exceptions, Fleet policies, Timeline and Cases records, and machine learning jobs to need rebuilding or replacing, and note that Sigma rules and OpenSearch correlation rules are different formats that need translation, testing and ownership. Record each rebuilt detection with its source rule, new rule, test evidence and reviewer, so audit teams can trace coverage across the change. Confirm with your auditors which evidence they require for the transition, since DeployOpen prepares evidence but independent assessors decide what is sufficient.
Where implementation projects usually run long
Schedules on this comparison tend to slip in four places: how the platform is deployed, how identity is wired in, how detections are tuned and how endpoint agents are rolled out. On the Elastic side, the first decision is whether to run Elastic packages on virtual machines or the ECK operator on Kubernetes. That choice sets the node roles, storage tiers and upgrade path your team will own for years. On the OpenSearch side, the choice is among Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, the Ansible playbook or Windows, and the Security Analytics plugin then has to be configured on top. Confirm which method your platform team already supports before anyone estimates the build.
Identity and detection work usually take longer than the cluster build. On OpenSearch, the Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token backends, and role mappings must be designed around your own groups. On Elastic, single sign-on sits in a paid tier, so confirm the license level before you design the login flow. Detection tuning is the other slow phase. Sigma rules in Security Analytics and Elastic's prebuilt rules both generate noise that has to be reviewed against your log sources, and each log type you add extends that review. Agent rollout follows the same pattern: Elastic Agent is managed through Fleet, while OpenSearch-based collection depends on the agents and shippers you choose, so confirm how many hosts and which operating systems are in scope.
Retention design is the phase most often reopened after go-live. Index lifecycle, hot, warm and cold storage and snapshot targets all have to match your legal hold and investigation needs, and Elasticsearch node roles, including the hot, warm, cold and frozen data tiers, shape what the storage plan can look like. Ask the vendor or your own team to document retention periods, storage sizing and the lifecycle policies in writing. DeployOpen sets durations and milestones only in a written, fixed scope agreed before work starts, so treat any timeline on this page as a question to answer in that scope, not as a planning figure.
Questions buyers ask before choosing or hiring help
Which Elastic Security detections need a paid tier?
On a self-managed deployment, the detection engine, machine learning anomaly detection and case management sit under Platinum, while endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. Basic keeps TLS, the file and native user realms and role-based access control free. Confirm current placement on the Elastic subscriptions page for every feature you plan to rely on. Ask your Elastic representative to map each detection type, response action and SSO requirement to a tier in writing. Platinum is no longer sold to new customers, so most new self-managed buyers of SIEM features will be pricing Enterprise or a cloud subscription. A detection that depends on a Platinum-only capability cannot be bought on its own, so check that before you design the rule set.
Can OpenSearch Security Analytics replace a commercial SIEM?
It can serve as the detection and correlation backend for many teams, but it does not replace the whole operating model. OpenSearch Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types, all under Apache-2.0, and the OpenSearch FAQ does not describe a paid edition. What you still own is the analyst workflow: case handling, triage queues, notification routing and any response automation must be designed and built, or integrated, by your team or a partner. Check the rule coverage you need in the Security Analytics documentation before assuming parity with a commercial rule library. A practical test is to replay a representative log set and count which required detections fire, and which you must write yourself.
What skills does a self-hosted SIEM need from our internal team?
The team needs three capabilities, and the gaps usually appear in the first one you skip.
- Search cluster operations: node roles (master-eligible, data tiers, ingest and coordinating), snapshot handling, certificate management and upgrades. A highly available Elasticsearch cluster needs at least three master-eligible nodes.
- Detection engineering: writing and tuning rules, mapping alerts to ATT&CK techniques, and reducing false positives until analysts trust the queue.
- Collection management: deploying and updating agents or collectors across endpoints, servers and cloud sources, including the change control that goes with them.
How much of this your team already owns decides whether you can run the platform alone. Ask any implementation partner for a written split of who operates each part, and which named roles your staff must fill.
How long does a SIEM migration usually take, and what sets it?
No single duration fits every estate, so treat any figure from a vendor or partner as a starting estimate to test against your own scope. The main drivers are the version gap, the volume and age of your indices, the number of rules to translate, and how many log sources must be re-pointed. OpenSearch is wire-compatible with Elasticsearch 7.10, can use indices from Elasticsearch 6.0 through 7.10, and supports rolling upgrades from those versions, so the path is short only if your current estate sits in that range. Confirm supported routes in the OpenSearch migration documentation before you plan. Detection content, dashboards and response workflows usually take more effort than moving indexed data. Ask for a fixed-scope plan with a written inventory of rules, sources and cutover steps.
Can our team run Elastic Security or OpenSearch without outside help?
Yes, if the team already runs Elasticsearch-class clusters and has detection engineers. If it does not, plan for outside help from the start. Both stacks install from packages, containers, Helm charts or an operator, so installation is rarely the hard part. The recurring work is what decides the outcome: patching, certificate rotation, snapshot testing, version upgrades and rule maintenance. OpenSearch versions in maintenance receive bug fixes and security patches but no new features, so your upgrade calendar follows the vendor's release cadence. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure, usually under fixed-scope agreements with written deliverables. Ongoing support and upgrades are available as a retainer. Ask any provider for a written split of what they run, what you run, and who responds outside business hours.
What does Platinum no longer being sold mean for new buyers?
New self-managed buyers cannot purchase Platinum, so the practical choices are Basic, Enterprise or Elastic Cloud, as Elastic's subscriptions page directs. For a SIEM buyer, the detection engine, machine learning anomaly detection and case management now sit in the Enterprise conversation or a cloud subscription, which changes the budget discussion. Existing Platinum customers should confirm their renewal path and support dates in writing. Elastic's end-of-life dates list end of maintenance for 8.x on January 15, 2027, with 8.x support ending July 15, 2027, and end of maintenance for the 9.x core stack on October 15, 2027. Build those dates into your plan, because a release that leaves maintenance forces an upgrade whether or not your team is ready.
Does the license change what we can build or offer internally?
Elastic Security runs on Elasticsearch and Kibana, which are distributed under Elastic License 2.0 by default, with SSPL 1.0 and AGPLv3 also offered for the source code. Elastic added AGPLv3 in September 2024, before the 8.16 release, as an OSI-approved open source option. ELv2 and SSPL are not OSI-approved. OpenSearch and OpenSearch Dashboards are released under Apache-2.0, and the OpenSearch FAQ does not describe a paid edition. For internal use, most teams focus on which edition they run and which distribution they deploy. If you plan to offer monitoring as a managed service to other organizations, have counsel review the applicable license against that model before design starts. Ask each vendor for its current license text in writing and record the version you deploy.
How DeployOpen helps you choose and implement either platform
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the choice between Elastic Security and OpenSearch Security Analytics can be tested against your environment before anything is committed. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. DeployOpen is not an official partner, reseller or certified provider of Elastic or OpenSearch, and it does not favor either platform. Quotes follow from the written scope, and DeployOpen does not publish a price list.
For this decision, a useful scope usually covers the detections you need on day one, the license tier each one requires on the Elastic side, the Sigma rule set and correlation logic you would build on the OpenSearch side, the Timeline or case workflow your analysts will use, and how identity integration, role-based access and audit logging will be configured. Ask whether the scope includes running a proof of concept against your own log sources, and confirm with Elastic and the OpenSearch project which features are covered by your chosen license or distribution before the statement of work is signed.
DeployOpen also runs security testing on applications, APIs, cloud and infrastructure, and AI systems, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, so independent auditors and certification bodies remain responsible for those outcomes. Ongoing support, upgrades and continuous testing are available as retainers, which matters for SIEM platforms because detection content, version support windows and rule maintenance recur after go-live. Ask for the retainer terms in writing alongside the initial quote.
