# Attack protection tuning
## The layers
Dashboard > Security > Attack Protection:
1. Bot Detection: scores login traffic by IP reputation and behavior; challenges suspected bots. Enable it; it is the cheapest layer.
2. Suspicious IP Throttling: throttles auth attempts from an IP after thresholds, before blocking accounts. This catches distributed guessing without punishing users.
3. Brute-Force Protection: blocks the account after N failed attempts for that account. The shield that pages you at 3am when a shared office IP trips it.
4. Breached Password Detection: checks passwords against breach corpuses at login/signup; options are block, notify, or notify-admin.
## Tuning without friendly fire
- Order matters: throttling before shields. Throttling absorbs the spray; the shield only fires on targeted account attacks.
- Shared IPs (offices, universities, VPNs): raise brute-force thresholds or rely more on throttling, or every typo storm blocks real users behind the NAT.
- Notify: enable the blocked-account email so users self-serve the unblock instead of filing tickets.
- Breached passwords: "block and require reset" for new signups; for existing users prefer "notify user" first, then escalate. Never silently allow a known-breached password on an admin account.
## Monitoring
Attack protection events are in tenant logs (separate event types). Stream them to your SIEM and alert on spikes, not on single blocks. A sudden 10x in throttled IPs is the signal; one blocked account is noise.
## What not to do
- Do not disable everything because of one false positive; tune the threshold.
- Do not load-test login with bad passwords against production; use a test tenant.
## Checklist
- Each layer enabled with deliberate thresholds before launch.
- Unblock path tested (do you know the clicks?).