# Sharing my rule update experience on Elastic Security Serverless **URL:** \ **Category:** SIEM\ **Created:** [August 21, 2026, 8:04pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853 "2026-08-21T20:04:31Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:04pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/1 "2026-08-21T20:04:31Z")
Hello, Just sharing my experience updating Elastic prebuilt Security rules after being away for about 1.5 months. When I logged back in, I had roughly **1,200 rule updates** waiting. That is fine in itself - I clicked **Update all** and expected the bulk update process to handle it. However, **36 rules showed conflicts** , even though I had never intentionally modified those rules. For each of those 36 rules, I then had to individually: - Open and review the conflict - Click **Save and accept** - Click **Update rule** - Deal with the deprecated-rule popup and click **Load rules** - Wait several seconds for the update to complete - Repeat the entire process for the next rule With roughly 10 seconds of clicking/navigation plus around 4 seconds of update time per rule, resolving 36 conflicts easily turns into **15-20 minutes of repetitive manual work**. There are really two issues here. First, I would like to understand **why prebuilt rules that I never modified are being reported as conflicting/modified in the first place**. If there is some migration, versioning, or other internal change causing this, the UI should make that clear. Second, even when conflicts are legitimate, the current workflow does not scale. Human review of a conflict can make sense, but forcing the administrator through the same multi-click update workflow 36 times does not. It would be much better to have something like: - Review all conflicting rules in one workflow - Multi-select rules and accept the Elastic version in bulk - An **"Accept upstream version for all"** option where appropriate - Clear visibility into exactly what caused each conflict - Batch/background processing of accepted updates - Removal or consolidation of the deprecated-rule popup during this process I fully understand that conflicting changes should not simply be overwritten without review. The problem is not the review itself - it is the amount of repetitive UI work required after that decision has been made. For a product with hundreds or thousands of prebuilt detection rules, this workflow needs to scale better. ![image](https://us1.discourse-cdn.com/elastic/original/3X/d/6/d698bba0928ebd0495cdb08e4ecc5d993887719e.png) ![image](https://us1.discourse-cdn.com/elastic/original/3X/0/8/086129e5492d0c9c9fa277d6926668fee5c62a10.png) Willem ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:15pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/2 "2026-08-21T20:15:34Z")
Oh, and during this process, my browser hanged multiple times... ![image](https://us1.discourse-cdn.com/elastic/original/3X/9/b/9b30b2b57d2cf70393b17059ba149d6398044a54.png) And the Save and accept button also sometimes stays greyed out for a long time.. ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [August 21, 2026, 8:16pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/3 "2026-08-21T20:16:40Z")
I have a similar experience, but we are basically postponing the update of Elastic rules as we use more our custom rules. > [@willemdh](#): > > First, I would like to understand **why prebuilt rules that I never modified are being reported as conflicting/modified in the first place**. If there is some migration, versioning, or other internal change causing this, the UI should make that clear. Do they have the `Modified` tag or they are just reporting a conflict that needs to be manually fixed? Some pre-built rules may show an unresolved conflict because they are changing types, for example, from `eql` to `esql`. > [@willemdh](#): > > - Deal with the deprecated-rule popup and click **Load rules** This pop-up is pretty annoying, I can not understand why every single update asks for this, another issue that we have is that trying to update the rule from the rule page will not work, because for some reason this pop-up will not show up, you need to go to the dedicate rule updates page and update the rules from there. ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:19pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/4 "2026-08-21T20:19:37Z")
Thanks for your feedback. They are all unmodified... ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:22pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/5 "2026-08-21T20:22:22Z")
Also I get this annoying popup too half of the time... ![image](https://us1.discourse-cdn.com/elastic/original/3X/3/d/3d8bbffb18faa3942e1ff0a088bd2095e5d13350.png) ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [August 21, 2026, 8:24pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/6 "2026-08-21T20:24:59Z")
Yeah, for example the rule **Process Discovery via Built-In Applications** , in my cluster this rule is unmodified, but it has an _Unresolved conflict_ tag because the type is changing from `eql` to `new_terms`. ![image](https://us1.discourse-cdn.com/elastic/original/3X/1/8/18bb7ba49e0e1c557ea8a438d3ad04a43cc395da.png) ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:27pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/7 "2026-08-21T20:27:48Z")
I honestly have serious concerns about the way this is progressing.. Several promises were made over the past years to improve this process, but I dont feel like its going in a good direction. Did anyone at Elastic even try this process him/herself...? How this gets through QA I dont know.. ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:34pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/8 "2026-08-21T20:34:59Z")
It seems like the hanging rules are all those who have many "modifications", like this one: ![image](https://us1.discourse-cdn.com/elastic/original/3X/e/7/e768fd715ffccbb182b396ece9f5c4896913fcb4.png) ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 21, 2026, 8:37pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/9 "2026-08-21T20:37:23Z")
![image](https://us1.discourse-cdn.com/elastic/original/3X/6/5/654da3dbc865d093239332ea2871dd404991fe14.png) This one took 14 seconds before the Save and accept button was no longer greyed out.... And 13 seconds the browser hanged after clicking Save and accept.... ---
**Author:** ![Maxim\_Palenov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maxim_palenov/32/122504_2.png) [@Maxim\_Palenov](https://discuss.elastic.co/u/Maxim_Palenov)\ **Post date:** [August 21, 2026, 9:59pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/10 "2026-08-21T21:59:39Z")
Hi @willemdh, Thanks for you using Security Solution from Elastic 🙏 I understand the difficulties you go through. And it's a really precious feedback. We'll definitely do our best to make prebuilt rules update UX smoother. And some of the things could be done faster while another could take much more time. It indeed a time consuming process to update prebuilt rules and preserve customisations. Though as immediate help in case you want to update only to the prebuilt rule versions provided by Elastic I may suggest using internal API the UI sits on. First fetch a list of prebuilt rules having updates ```bash KBN= AUTH="Authorization: ApiKey " # or use username/password auth curl -sk "$KBN/internal/detection_engine/prebuilt_rules/upgrade/_review" -X POST -H "$AUTH" -H 'kbn-xsrf: true' -H 'elastic-api-version: 1' -H 'x-elastic-internal-origin: Kibana' -H 'Content-Type: application/json' -d '{"page":1,"per_page":100}' | jq '[.rules[] | {rule_id, version: .target_rule.version, revision, name: .current_rule.name}]' ``` then dry run the update with rule\_id, version and revision substituted ```bash curl -sk "$KBN/internal/detection_engine/prebuilt_rules/upgrade/_perform" -X POST -H "$AUTH" -H 'kbn-xsrf: true' -H 'elastic-api-version: 1' -H 'x-elastic-internal-origin: Kibana' -H 'Content-Type: application/json' -d '{ "mode": "SPECIFIC_RULES", "dry_run": true, "pick_version": "TARGET", "rules": [ { "rule_id": "9a1a2dae-0b5f-4c3d-8305-a268d404c306", "version": 214, "revision": 0 }, { "rule_id": "e26f042e-c590-4e82-8e05-41e81bd822ad", "version": 111, "revision": 3 } ] }' ``` and finally drop `"dry_run": true` and run real prebuilt rules update process. I wouldn't recommend using it all the time. Only when you struggle with a lot of conflicts and want to update to the new Elastic shipped version. ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 22, 2026, 7:01am UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/11 "2026-08-22T07:01:10Z")
Thanks for your suggestion to use the API, but this is for my personal home environment which has like 4 agents and a firewall. In an Enterprise env ofc we should use automation, but this should just work fluently ootb from the ui. And certainly in Serverless it should not hang and take me an hour to update 36 rules I didn't even modify. ---
**Author:** ![Kseniiaign](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kseniiaign/32/105250_2.png) [@Kseniiaign](https://discuss.elastic.co/u/Kseniiaign)\ **Post date:** [August 24, 2026, 9:33am UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/12 "2026-08-24T09:33:09Z")
Hi Willem, thank you for your feedback, and thanks for your input Leandro. We are planning improvements for this process, it is indeed not a good experience and we intend to fix it. Some other plans have take n priority right now, but we'll look how this can be planned sooner. ---
**Author:** ![dongnx](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dongnx/32/148154_2.png) [@dongnx](https://discuss.elastic.co/u/dongnx)\ **Post date:** [September 3, 2026, 1:04am UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/13 "2026-09-03T01:04:22Z")
The example leandrojmp gave is the part I would want measured, not just fixed: Process Discovery via Built-In Applications changing from eql to new\_terms. Those two rule types do not fire under the same conditions. A new\_terms rule only fires on a value it has not seen inside its history window, so after the update that rule can stay quiet on activity an eql rule would have matched every time. Same rule name, same "covered" row on the dashboard. That leaves a question nobody in this thread has asked yet: after Update all, is the rule set still firing on the things it claims to cover? The conflict count tells you how many rules changed. It does not tell you how many changed semantics. You already said the API is not the answer for a four-agent home setup, and for doing the update itself that seems fair to me. This is a different use: one read, once, to see what the update changed. GET /api/detection\_engine/rules/\_find lists each rule with its type. Diff type per rule\_id against a pre-update export. Any rule whose type changed is a rule whose firing condition changed, whether or not it was flagged as a conflict. That is a smaller set than 1,200 and a different set than the 36. On the wider "a rule exists" versus "a rule fires" gap, the only number I can offer is one I measured myself, on a different stack: 24 ATT&CK techniques replayed against a default Wazuh build, 3 produced alerts. That is Wazuh, not Elastic, and it is one build, not a population, so I am not claiming it transfers. The method transfers: replay, then count what actually fired, instead of counting what the coverage page says is covered. ---
**Author:** ![dot-mike](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dot-mike/32/143339_2.png) [@dot-mike](https://discuss.elastic.co/u/dot-mike)\ **Post date:** [September 25, 2026, 12:27pm UTC](https://discuss.elastic.co/t/sharing-my-rule-update-experience-on-elastic-security-serverless/389853/15 "2026-09-25T12:27:47Z")
I also have bad experience wit this. Today I saw more than 200 rules have updated and they all had conflicts. But the conflicts were not because I modified the rules, it's because elastic had changed how they threat rules targeting specific Elastic-stack versions. So instead of manually punching in review -\> accept on all those updates, I used curl to accept them all. Not a good approach! Export `KIBANA_URL` and `KIBANA_API_KEY` accordingly. This will target all rules with filter `NOT_CUSTOMIZED` which basically means you didn't modify it by hand. ```auto curl -s "$KIBANA_URL/internal/detection_engine/prebuilt_rules/upgrade/_perform" \ -X POST -H "Authorization: ApiKey $KIBANA_API_KEY" \ -H 'kbn-xsrf: true' -H 'elastic-api-version: 1' \ -H 'x-elastic-internal-origin: Kibana' -H 'Content-Type: application/json' \ -d '{"mode":"ALL_RULES","pick_version":"TARGET","filter":{"customization_status":"NOT_CUSTOMIZED"}}' \ | jq '{summary, errors}' ``` Result: ```auto { "summary": { "total": 197, "skipped": 0, "succeeded": 197, "failed": 0 }, "errors": [] } ```