Hi everyone! 👋 I'm pretty new to the cybersecurity side of things, coming from a Salesforce and RevOps background where everything is usually... well, online. I've been helping my company evaluate CrowdStrike Falcon, and a question came up that I couldn't find a super clear answer on.
We have a number of field engineers with laptops that can go offline for days at a time during installations at client sites with no internet. My understanding is that Falcon relies heavily on its cloud intelligence. I'm worried about the protection gap when those machines are disconnected.
Could someone explain how Falcon typically handles this? Does it just rely on the last known good policy and definitions until it can phone home again? Is there a specific setting or best practice we should configure for these types of intermittent-connectivity machines? I'm thinking about things like scheduled scans or how updates are applied once they reconnect.
I want to make sure we set this up correctly from the start, and I know you all have real-world experience. Thanks!
I lead security operations for a logistics company with about 2000 endpoints globally; we've been on Falcon Complete for two years and have exactly this scenario with technicians in remote warehouses.
Here's how offline handling works, based on our configuration and support tickets:
1. **Local cache and enforcement**: The sensor maintains a local cache of prevention policies and IOCs. The critical detail is that the cache size is configurable. Our default was 7 days of threat intelligence, but we expanded it to 14 for our field units, which requires a support ticket. It continues to block known-bad hashes and enforce firewall/exploit policies from this cache.
2. **Detection vs. prevention gap**: Machine learning detections for new malware variants require a cloud query. A truly novel, unseen executable on an offline machine may not be flagged immediately. Prevention, based on known IOCs and behavioral rules like ransomware canary file protection, continues uninterrupted. The offline limitation is primarily in net-new, unknown malware classification.
3. **Update behavior on reconnect**: The sensor queues event data and performs a differential sync upon reconnect. Policy updates are applied automatically. The key setting for you is the "Sensor Update Policy," which controls how aggressively it pulls the new sensor version. For intermittent machines, we set it to "Defer as long as possible" within a major version to avoid a large download consuming limited bandwidth right after reconnect.
4. **Recommended configuration for field units**: You should create a dedicated device group for these laptops. Besides the cache expansion, we enabled scheduled weekly quick scans during offline periods and set the "Cloud Activity" policy to "Full" to ensure all queued data syncs immediately when a network is available. The biggest operational tweak was adjusting our alerting thresholds for these machines to account for delayed event reporting.
My pick is Falcon is workable for this if you size the local cache correctly and segment the devices. It's the right choice if your primary threat model is widespread known-bad activity and behavioral attacks. It's a weaker fit if these machines are high-value targets constantly receiving unique, first-seen malware. To make a clean call, tell us the typical maximum offline duration and what type of sensitive data or access those laptops hold.
prove it with data
That 14-day cache you got via a support ticket? It's a band-aid, and a pretty telling one. The "gap" you mention is the whole product.
CrowdStrike sells on the cloud brain. Offline, you're running on stale IOCs and whatever behavioral rules shipped last. The idea that a novel executable on an offline machine "may not be flagged" is generous. It won't be flagged, full stop. Their local ML model is a skeleton crew.
You pay for the cloud, but your most vulnerable assets are cut off from it for days. That's not a configuration issue, it's a design flaw they're papering over with cache extensions.
Prove it
You're not wrong about the local ML being limited, it's definitely a lighter model. But calling the local cache a "band-aid" misses how this actually plays out on real, offline assets.
The bigger issue I've seen isn't missing a brand new zero-day trojan. It's that offline, you lose all the context from the cloud. That executable from a vendor's USB drive might be fine, but Falcon can't check its prevalence across your own fleet or see if it's been touching command and control servers elsewhere in your org. The isolation cuts both ways.
It's less about the product having a design flaw and more about accepting that a cloud-native tool has a fundamental operational constraint. You either design your offline workflows around that gap, or you look at a different architecture altogether. We ended up locking down those laptops with AppLocker policies that were far more restrictive than our online ones, because you're right, you can't rely on the cloud brain.
it worked on my machine