Managing CrowdStrike Falcon sensor versions effectively is critical for maintaining security while ensuring system stability. This guide explains the different version management strategies including Auto-Latest, N-1, N-2, and fixed versioning.
Understanding Sensor Version Management
CrowdStrike provides two approaches to sensor version management:
- Fixed (Manual): Lock sensors to a specific version number
- Automated: Let CrowdStrike automatically update sensors based on release tiers
CrowdStrike Recommendation: Update sensors monthly and maintain all hosts at N-2 or newer for optimal protection and performance.
Automated Version Options
Auto - Early Adopter
Hosts update to early adopter builds 4 days before general availability. Use for:
- Organizations wanting to test and provide feedback
- Dedicated test environments only
- Early identification of potential issues
Note: You must enable "Show early adopter sensor builds" in your policy to use this option.
Auto - Latest (N)
Hosts update to the newest version when scheduled releases happen. Use for:
- Test and QA environments
- Non-production hosts for validation
- Organizations with robust testing processes
Auto - N-1 (One Version Behind)
Hosts update to the second-newest version. Use for:
- Pilot groups and limited production testing
- Organizations wanting near-latest with slight delay
- Environments requiring balance of features and stability
Auto - N-2 (Two Versions Behind)
Hosts update to the third-newest version. Use for:
- Production environments (recommended)
- Business-critical systems
- Organizations prioritizing stability
Important: If the latest sensor build is rolled back or removed from service, hosts on Auto N-1 and N-2 will not revert to a previous build. These policies remain on their known stable version.
Fixed Version Options
Specific Version Number
Hosts upgrade or downgrade to the selected version and remain on it until you manually select a new version.
Use case: Organizations preferring hands-on testing and controlled rollouts.
Sensor Version Updates Off
The cloud won't push any version changes. Sensors can be on different versions across hosts.
Use case: Manual sensor management, maintenance operations, or self-service updating through tools like SCCM or JAMF.
Version Rollout Timeline
When CrowdStrike releases a new sensor version:
| Day | Event | Affected Policies |
|---|---|---|
| Day 0 | Early Adopter build available | Auto - Early Adopter |
| Day 4 | General Availability release | Auto - Latest |
| Day 4 | Previous Latest becomes N-1 | Auto - N-1 |
| Day 4 | Previous N-1 becomes N-2 | Auto - N-2 |
Testing Sensor Builds as an Early Adopter
CrowdStrike makes new sensor builds available for testing prior to official release:
-
- **Enable Early Adopter Builds**
-
Go to Host Setup and Management > Deploy > Sensor Update Policies
-
Select your test policy
-
On the Sensor Settings tab, select Show early adopter sensor builds
-
Select Early Adopter Version
-
Choose Auto - Early Adopter from the sensor version dropdown
-
Click Save
-
Provide Feedback
-
Click Start Survey to provide feedback about any early adopter build
Early adopter builds are available 4 days before general availability.
Recommended Deployment Strategy
Create a tiered deployment structure for controlled rollouts:
| Tier | Host Group | Version Setting | Hosts |
|---|---|---|---|
| 1 | Test-QA Group | Auto - Latest | Non-production test hosts |
| 2 | Tech Pilot Group | Auto - N-1 or Specific | Limited non-critical production |
| 3 | Business Pilot Group | Auto - N-1 or Specific | Multi-department production sample |
| 4 | Production (Default) | Auto - N-2 or Specific | All remaining hosts |
Workflow
-
- Test-QA Group receives new version first (Auto - Latest)
- After validation, update Tech Pilot to that version
- After broader testing, update Business Pilot
- Finally, update Production when confident
Configuring Sensor Version in a Policy
-
- Go to **Host Setup and Management** > **Deploy** > **Sensor Update Policies**
- Click on the policy you want to modify
- On the **Sensor Settings** tab, select your desired version option:
-
Auto - Early Adopter
-
Auto - Latest
-
Auto - N-1
-
Auto - N-2
-
Specific version number
-
Sensor version updates off
-
Click Save, then confirm
Long-Term Support (LTS) Sensors
For organizations that value stability over new features, CrowdStrike offers Long-Term Support sensors:
- Support duration: 12 months (vs 6 months for regular sensors)
- Revert window: 365 days (vs 180 days for regular sensors)
- Use case: Environments where change management requires extended validation
Best Practices
- Don't fall behind: Never let sensors get older than N-2
- Monthly updates: Update sensors at least monthly
- Test first: Always validate new versions in test environments
- Use tiers: Implement a tiered rollout strategy
- Monitor: Watch for issues after each version change
- Document: Track which versions are deployed where