Anyone else's false positive rate spike after the last rule update?

That's a scary point about renewals I hadn't considered. So you're basically creating evidence against yourself for them to use later.

But if you don't make the temporary exclusion, your business can't function right now because of the false positives. Isn't the bigger risk of downtime immediate, while the contract issue is a future problem?

Yes, we saw the same spike after that date. It really stood out on our support portal logins, which had been quiet for months.

Are the geographic regions you're seeing issues with ones that might have more mobile traffic? I'm wondering if a change in how mobile sessions are scored is part of this.

Yes, we noticed something similar, though a bit later. I'm fairly new to Imperva myself, so I'm still learning the ropes, but we had a sudden increase in false positives on our contact forms around the 14th. It wasn't immediate, but it was a clear jump from the baseline.

It's making me a bit nervous because we rely on those leads. Did you find that the challenges were happening at a specific step in your checkout, like entering an address? I'm trying to figure out if there's a common pattern I should look for in our own logs.

Contact forms are a bad proxy. You're new, so here's what you're missing: the baseline noise is useless without segmenting by source.

Your "clear jump" is meaningless if you don't split out organic, paid, and direct traffic first. A single ad campaign launching on the 13th would look exactly like your spike.

Pull logs for the form POST. Look for `BOT000456` and the session-based sub-rules others mentioned. If you're not seeing those, your problem is different and you're lumping it in with this update.

Segmenting by sub-rule ID is the correct first step, but a temporary exclusion is a risk. If you exclude a behavioral rule, you're discarding the model's training signal for that endpoint. The next global update will likely overcorrect again because your traffic pattern is now an outlier.

We traced BOT000123's spike to its interaction with older session-concurrency rules. The sub-rule wasn't the root cause, it was just the new trigger. The real fix was adjusting the velocity threshold in our own custom rule, which stopped the cascade without blinding the system.

Did you check if your login endpoint had any custom rules that might have had their weight inadvertently changed by the update? That was the case for us.

You make a really important point about the training signal. It's a downside of exclusions that doesn't get talked about enough.

I think the risk varies by endpoint though. For something as critical as login or checkout, sometimes accepting that blind spot is the pragmatic choice to stop the bleeding, even if it sets you up for a future recalibration. It's a trade-off between immediate user impact and long-term tuning.

The interaction with custom rules is a great catch. We found a similar issue where a rule we'd set to 'monitor' on our payment page was suddenly being given full enforcement weight after the update, which we only spotted by comparing configuration snapshots.

Your distinction about critical endpoints is a valid one, and it underscores the operational reality of choosing the lesser of two evils. The trade-off you describe, between immediate user friction and long-term model degradation, is precisely the kind of decision that lacks clear guidance from vendors.

That said, the danger in always choosing the exclusion for critical paths is that it can become a reflexive, permanent fix. Over time, you can end up with a patchwork of blind spots on your most important user actions, which doesn't just harm the model's training but can create a massive security gap if an attacker probes those now-unmonitored endpoints. Perhaps the more sustainable, though administratively heavier, approach is to treat the exclusion strictly as a stopgap and immediately begin crafting a targeted custom rule to replace it, preserving some detection logic while you work on the proper threshold tuning.