Evaluate your Premium trial

This guide is an evaluation worksheet, not a product tour. Its purpose is to help you measure what Premium actually changes in your environment — so your upgrade decision is based on evidence, not expectations.

Complete Upgrade and configure Premium before running these tests.

---

Before activating Premium features

Record baseline values before you enable any Premium features. You cannot compare results without a starting point.

Metric	Baseline (before)	Trial result (after)	Change
Proactive remediations per day (blocklist hits)
Reactive remediations per day (real-time decisions)
Alert volume per week
Alerts classified as scanner or crawler noise
Time spent manually propagating decisions (hours/week)
Console IP investigations per week
Security Engine health incidents per month

Record these numbers before enabling Remediation Sync, Background Noise, or any additional blocklist subscriptions.

---

Evaluation timeline

Phase	Focus
Before trial	Establish baseline
First 48 hours	Verify activation and data flow
Week 1	Protection and noise reduction
Weeks 2–3	Operations, collaboration, and automation
Final week	Review evidence and decide

Skip sections that do not apply to your environment. A small DevOps team does not need the MSP isolation tests. An MSP can start directly with the multi-organization and API tests.

---

Test: Expanded Community Blocklist coverage

Outcome: Confirm that your Security Engines are receiving and applying the 50k-IP Premium blocklist instead of the 3k Community list.

Prerequisites: At least one Security Engine enrolled in the Premium organization.

Procedure:

1. On a Security Engine, run cscli decisions list --origin lists and note the number of active entries from the Community Blocklist before and after the upgrade.
2. Compare the count. The Premium list should contain significantly more entries than the Community list.

What to look for: An increase in proactive remediations (blocklist-sourced decisions) visible on the Console dashboard. The ratio of proactive-to-reactive remediations should shift toward proactive.

Observed benchmark

Customers in the CrowdSec network who move from the Community to the Premium blocklist tier report increased proactive blocking coverage. Actual improvement depends on your traffic profile, the services you expose, and the attack types prevalent in your region. Establish your own baseline.

---

Test: Threat Forecast Blocklist

Outcome: Confirm that a Threat Forecast blocklist has been generated for your organization and is being applied.

Prerequisites: At least one Security Engine actively sharing signals in the Premium organization.

Procedure:

1. Navigate to Blocklists → Threat Forecast in the Console.
2. Confirm the list is present and contains entries.
3. Check that enrolled Security Engines have it in their active decision set (cscli decisions list --origin lists).
4. Return after 7 days and note whether the list has updated.

What to look for: Entries tailored to the attack patterns your organization is actually seeing — different from the general Community Blocklist. The list updates periodically as your engines share new signals.

---

Test: Background Noise filtering

Outcome: Confirm that scanner and crawler traffic is being removed from your alert view.

Prerequisites: Background Noise filtering enabled (Upgrade and configure guide, step: Enable Background Noise filtering).

Activate: Enable at Low, Medium, or High. Start at Low or Medium.

Procedure:

1. Record the number of alerts classified as "background noise" on the Alerts page before enabling.
2. Enable filtering at your chosen level.
3. Return after 24 hours and record the new alert count.
4. Note how many alerts remain that are not classified as background noise.

Measure:

• Alerts before filtering
• Alerts after filtering
• Percentage reduction

Success criteria: A visible reduction in scanner and crawler alerts without removing alerts from IPs that are relevant to your infrastructure.

---

Test: Remediation Sync

Outcome: Confirm that a decision created in one place is applied to all enrolled Security Engines and integrations automatically.

Prerequisites: At least two enrolled Security Engines or one Engine and one blocklist integration. Remediation Sync enabled.

Procedure:

1. In the Console, go to Decisions and add a temporary test decision for an IP you control (for example, a test server IP).
2. Wait 2–5 minutes.
3. On each enrolled Security Engine, run cscli decisions list and confirm the test IP appears.
4. Remove the decision from the Console.
5. Confirm removal on each engine.

Measure:

• Propagation time (minutes)
• Number of engines reached without manual action
• Any engines that did not receive the decision (investigate connectivity)

Success criteria: The decision reaches all expected endpoints without any manual per-engine action.

---

Test: Alert retention and historical analysis

Outcome: Confirm that 365-day retention is active and that historical data is accessible for investigation.

Prerequisites: Premium plan active.

Procedure:

1. Go to Alerts in the Console and set the date range to the maximum available.
2. Confirm the range now extends to 365 days (or to the date you upgraded, whichever is shorter — historical data from before the upgrade is not backfilled to Premium retention).
3. Filter by a specific attack type or Security Engine and look for patterns over time.

What to look for: Whether you can identify recurring attackers, seasonal patterns, or evolving attack vectors that were not visible under the 60-day Community retention window.

warning

Premium retention applies from the upgrade date forward. Data that existed before the upgrade under Community retention (60 days) is not retroactively extended. Plan your evaluation accordingly.

---

Test: IP investigation workflow

Outcome: Confirm that the increased Console investigation quota (100/week) is sufficient for your investigation workload.

Prerequisites: Premium plan active.

Procedure:

1. Identify 5–10 suspicious IPs from your current alert view.
2. Investigate each one directly in the Console using the IP reputation panel.
3. Note the reputation, behavior classification, MITRE ATT&CK tags, and any fingerprint data.
4. Compare the investigation experience with your previous workflow (external CTI tools, manual lookups).

What to look for: Whether the in-Console investigation covers what you previously needed external tools for, and whether the quota (100/week) is enough for your team's investigation pace.

---

Test: Team access and collaboration

Outcome: Confirm that multiple team members can work in the Console simultaneously without access conflicts.

Prerequisites: At least one additional team member invited (Upgrade and configure guide, step: Invite team members).

Procedure:

1. Have two team members log in simultaneously.
2. Have one investigate alerts while the other manages allowlists or reviews the dashboard.
3. Confirm changes made by one member are visible to the other without delay.

Success criteria: No access conflicts. Role-based permissions (Viewer, Editor, Admin) enforce the correct boundaries.

---

Test: Push notifications

Outcome: Confirm that your team receives notifications in existing tools when Security Engine health events occur.

Prerequisites: At least one notification integration connected.

Procedure:

1. Connect a Slack channel, PagerDuty service, or webhook endpoint.
2. Take one enrolled Security Engine offline or stop its service temporarily.
3. Confirm a notification arrives in the connected tool within the expected time.
4. Restart the engine and confirm the recovery notification (if configured).

Success criteria: Notification received without polling the Console.

---

Test: Service API and automation (MSP / enterprise)

Outcome: Confirm that Console operations can be performed programmatically via the Service API.

Prerequisites: Service API credentials created.

Procedure:

1. Use the SAPI to retrieve the list of enrolled Security Engines.
2. Use the SAPI to create a custom blocklist with 5–10 test IPs.
3. Subscribe the organization to the custom blocklist via API.
4. Confirm the IPs appear in active decisions on enrolled engines.
5. Delete the custom blocklist via API and confirm removal.

Service API reference →

---

Test: Multi-organization isolation (MSP)

Outcome: Confirm that separate organizations provide complete data isolation.

Prerequisites: At least two Premium organizations created.

Procedure:

1. Enroll one Security Engine in each organization.
2. Switch between organizations in the Console.
3. Confirm that alerts, decisions, and engines from Organization A are not visible when viewing Organization B.
4. Create a decision in Organization A and confirm it does not appear in Organization B.

Success criteria: Complete isolation. No data leaks between organizations.

---

Evaluation scorecard

Fill this in during the final week of your trial.

Goal	Baseline	Trial result	Evidence collected	Valuable?
Increase proactive blocks
Reduce irrelevant alerts
Reduce manual decision propagation
Improve investigation speed
Team collaboration without conflicts
Receive proactive health notifications
Automate engine enrollment
Isolate client or environment data

Use this scorecard when presenting results to stakeholders or making the upgrade decision.

---

If you need help setting up a specific test or interpreting results, contact CrowdSec support.

Continue to Premium feature reference →