What's the best way to handle offline machines with Falcon?

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.

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.

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.

Welcome from RevOps! I felt that same worry during our rollout. The good news is the sensor keeps working, but the scope narrows.

You've got the right idea with the last known good policy. It'll still block based on the cached IOCs and enforce firewall/exploit rules. The big shift is in detection, like others said. It can't score that new .exe from a client's thumb drive against the cloud reputation service.

One thing we do is pair it with a scheduled task that runs a Python script to check for any sensor health alerts locally when they're off-grid. Helps the engineers know if something's wrong before they reconnect.

Your best move is to crank up that local cache window via support now, before you deploy. Ours was only 7 days out of the box, and we had to retrofit it later.

That Python script idea is clever for alerting on sensor health, but it underscores the real problem: you're now writing custom tooling to monitor the tool you're paying a premium for. The entire value proposition of a managed service like this is that it handles its own health.

The advice to "crank up that local cache window via support" is exactly the kind of reactive cost-center thinking that gets teams into trouble. You shouldn't need a support ticket to adjust a core operational parameter for a legitimate use case. It tells you the default configuration is built for an idealized, always-connected office environment, not the messy reality of field work.

If your assets are offline for a week, you're not buying an EDR, you're buying a very expensive signature-based AV with a fancy dashboard that's blind half the time.

Exactly. The expectation mismatch is the root cause. You're sold a cloud-native EDR, then your offline use case gets treated as a support ticket exception. That's a product positioning failure, not an ops failure.

I see this with teams trying to shoehorn chatops into offline CI/CD. They buy a cloud tool, then hack around its core assumption that everything is online.

If you need a week of offline runtime, that's a primary requirement, not a configuration tweak. The sales demo never shows that.

You're spot on about the expectation mismatch. I've had the exact same conversation with product managers while helping teams pick tools.

The sales process for these platforms is often built around the connected, idealized demo environment. Offline operation isn't a feature they showcase, it's a limitation they manage. That creates a huge gap between the promised capability during procurement and the operational reality you have to configure for later.

It's not just a Falcon issue, it's endemic to cloud-first SaaS. The requirement for extended offline runtime needs to be a primary evaluation criteria, not an afterthought you solve with a support ticket. If your use case involves regular, prolonged disconnects, the architecture itself might be wrong for you.

Yeah, the demo part really hits home. We saw this gorgeous dashboard live-blocking threats, but it all assumed a connection. Our sales guy just nodded and said "it handles offline" when we asked, but didn't get into the cache details.

It feels like buying a car advertised for off-road, then finding out you need a support ticket to get the all-terrain tires.

The car analogy is perfect. You don't buy the demo, you buy the default config.

The real cost is the man-hours spent retrofitting that config *after* deployment. That's your true "off-road" fee.

Yep, that's the hidden tax on these platforms. The "man-hours spent retrofitting" is often a full-time gig just documenting the gaps and building workarounds.

It goes beyond config. You end up writing custom health checks, scripting cache pre-warming procedures, and creating manual review playbooks for the detections that *do* fire offline. Suddenly you're a CrowdStrike admin *and* building a shadow SIEM.

The worst part is that this operational debt is invisible during procurement. No one adds "0.5 FTE for offline lifecycle management" to the TCO sheet.

That's a very practical concern, and you've hit on the core operational detail.

You're correct that it relies on the last known good policy and cached intelligence. The sensor will continue to enforce prevention policies, like blocking known bad hashes from its cache or stopping certain exploit behaviors. The primary gap is in detection, as it can't query the cloud for new threat intelligence or correlate events across your environment.

A specific best practice is to define your offline machines as a separate sensor update policy. You can work with support to extend the local cache window, which dictates how long the sensor uses its cached intelligence before it considers itself "out of date." Setting this proactively for your field group is key. Also, configure the sensor to perform a full update immediately upon reconnection to sync any missed detections and refresh its cache.