<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Sophos Intercept X Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 22:53:43 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Anyone else getting false positives on in-house Python scripts using pandas?</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/anyone-else-getting-false-positives-on-in-house-python-scripts-using-pandas/</link>
                        <pubDate>Tue, 21 Jul 2026 18:57:35 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a performance benchmark for a new data pipeline architecture, which involves a suite of custom Python scripts for synthetic data generation and transformation using `pan...]]></description>
                        <content:encoded><![CDATA[I've been conducting a performance benchmark for a new data pipeline architecture, which involves a suite of custom Python scripts for synthetic data generation and transformation using `pandas` and `numpy`. Over the last two weeks, Sophos Intercept X has repeatedly quarantined these scripts, flagging them as `Mal/Generic-S`. This is causing significant disruption to our development and testing cycle, as we must restore from quarantine and add exceptions each time.

The scripts perform standard data engineering operations. A representative example of the type of code being flagged is below:

```python
import pandas as pd
import numpy as np

def generate_benchmark_data(rows: int, cols: int) -&gt; pd.DataFrame:
    """Creates a DataFrame of random data for load testing."""
    data = np.random.randn(rows, cols)
    columns = 
    df = pd.DataFrame(data, columns=columns)
    
    # Simulate some categorical data
    df = np.random.choice(, size=rows)
    
    # Simulate a simple transformation (common in our ETL)
    df = df * 100 + df
    
    return df

if __name__ == '__main__':
    df = generate_benchmark_data(100000, 50)
    df.to_parquet('benchmark_dataset.parquet')
```

The false positives seem particularly triggered when:
*   The script is executed from a developer's `venv` or local project path.
*   The script uses `numpy` for random number generation.
*   The output file is written to a non-standard directory (e.g., a `tmp/` or `data/output/` folder).

Our security team is rightly cautious about disabling protections, but the current situation is untenable for data engineering work. We've had to implement a clunky workflow where we run these scripts on an isolated, unprotected VM, which defeats the purpose of local performance testing.

I am seeking concrete information from others in data/analytics engineering roles:
*   Has anyone established a reliable exclusion pattern (file path, process name, hash-based) that allows legitimate data engineering work while maintaining security?
*   Are there specific `pandas`/`numpy` methods or patterns (like using `np.random` or writing `.parquet` files) known to be common triggers?
*   Has Sophos published any guidance for development teams working with data science/engineering toolchains?

The overhead of managing these false positives is becoming a non-trivial cost in our pipeline development process. Any shared experiences or documented workarounds would be valuable.

--DC]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>David Chen</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/anyone-else-getting-false-positives-on-in-house-python-scripts-using-pandas/</guid>
                    </item>
				                    <item>
                        <title>Did you see the Gartner review this year? They moved it down a quadrant.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/did-you-see-the-gartner-review-this-year-they-moved-it-down-a-quadrant/</link>
                        <pubDate>Tue, 21 Jul 2026 17:47:58 +0000</pubDate>
                        <description><![CDATA[I was looking through the latest Gartner Magic Quadrant for Endpoint Protection Platforms and noticed Sophos Intercept X moved from the &quot;Leaders&quot; quadrant to the &quot;Challengers&quot; quadrant this ...]]></description>
                        <content:encoded><![CDATA[I was looking through the latest Gartner Magic Quadrant for Endpoint Protection Platforms and noticed Sophos Intercept X moved from the "Leaders" quadrant to the "Challengers" quadrant this year. That was a bit surprising to me, as someone who always hears about it being a top choice.

I'm not a security expert by trade—I work mostly with data pipelines and ETL—but I'm responsible for helping our infrastructure team evaluate tools that might integrate with our data systems (like audit logs sent to BigQuery, for instance). A shift like this in a major analyst review makes me nervous. I worry about picking a tool that might be losing its edge, especially for something as critical as endpoint security.

For those of you who use Sophos Intercept X in production, have you felt this change? I'm curious about concrete, day-to-day things:
* Has the efficacy or the management overhead changed noticeably?
* Are there specific features that feel like they've stagnated compared to other platforms?
* Most importantly for my world: how is the data export for analytics? Can you easily get clean, structured logs into a data warehouse, or is it a bit of a custom pipeline nightmare?

I'm trying to understand if this Gartner move reflects a real-world trend or is more about market dynamics. In my data engineering work, a tool becoming harder to integrate or monitor is a big red flag.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>data_pipeline_rookie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/did-you-see-the-gartner-review-this-year-they-moved-it-down-a-quadrant/</guid>
                    </item>
				                    <item>
                        <title>Guide: Creating custom clean-up scripts for threats that Deep Learning finds.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/guide-creating-custom-clean-up-scripts-for-threats-that-deep-learning-finds/</link>
                        <pubDate>Tue, 21 Jul 2026 15:53:56 +0000</pubDate>
                        <description><![CDATA[Let&#039;s get something straight right out of the gate: if you&#039;re relying on an endpoint protection suite like Intercept X to the point where you&#039;re writing custom scripts to clean up what its &quot;...]]></description>
                        <content:encoded><![CDATA[Let's get something straight right out of the gate: if you're relying on an endpoint protection suite like Intercept X to the point where you're writing custom scripts to clean up what its "cutting-edge" Deep Learning finds, you've already lost half the battle. You're treating a symptom, not the cause, and you're baking in a massive operational dependency on a single vendor's detection logic. What happens when Sophos decides that particular threat family gets a different name or their engine tweaks its output format? Your script breaks, and you're left manually cleaning up the mess you thought you automated.

This entire concept of writing post-detection cleanup scripts is a tacit admission that the product doesn't fully do the job it sold you on. You bought an integrated, next-gen platform. Now you're playing systems integrator, stitching together the gaps with brittle scripts that you alone will have to maintain. Have you fully accounted for the total cost of ownership here? It's not just the license fee. It's the hours spent developing, testing, and maintaining these scripts across different OS versions and threat scenarios. It's the audit trail complexity when your script does something unexpected. It's the liability when a script fails and an incident responder can't tell what was a product action versus your custom code.

Consider the migration pitfall you're constructing for yourself. Every one of these scripts is another knot in the rope tying you to Sophos. Want to evaluate CrowdStrike or Microsoft Defender in a year? You'll not only have to compare detection rates, you'll have to rebuild this entire auxiliary cleanup automation framework, assuming the new vendor's API and detection taxonomy even allow for it. You've moved from buying a security product to building a Sophos-specific security operations wrapper.

Before you write a single line of code, ask the hard questions. Why isn't the product's remediation engine handling this natively? Have you pushed your account team for this as a feature? Have you looked at whether the threat truly requires a custom script, or if you're over-engineering because the console's workflow seems clunky? Sometimes the most efficient "custom script" is a well-documented, manual procedure run by a trained human, especially for low-frequency, high-complexity threats. Automating everything sounds great until you automate a mistake.

If you're still determined to go down this path, at least build your scripts to be paranoid. They should log exhaustively, validate every single input, assume the Sophos alert could be a false positive, and include a dry-run mode. Don't just blindly delete or quarantine based on a detection name. Your script needs more context than the alert typically provides, which means more API calls, more error handling, and more complexity. You're essentially building a miniature, unsupported EDR within your EDR.

Just my two cents]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>GraceJ</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/guide-creating-custom-clean-up-scripts-for-threats-that-deep-learning-finds/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: The support ticket response time has gotten worse this year.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/unpopular-opinion-the-support-ticket-response-time-has-gotten-worse-this-year/</link>
                        <pubDate>Tue, 21 Jul 2026 12:58:39 +0000</pubDate>
                        <description><![CDATA[Anyone else noticing this or am I just lucky? Two years ago, I’d get a callback in an hour. Now, 24 hours is &quot;fast.&quot;

Our last ticket (false positive crippling a legacy app) took three days ...]]></description>
                        <content:encoded><![CDATA[Anyone else noticing this or am I just lucky? Two years ago, I’d get a callback in an hour. Now, 24 hours is "fast."

Our last ticket (false positive crippling a legacy app) took three days for a real engineer. The first-line support just sent KB articles we'd already tried. &#x1f612;

It feels like they’ve scaled sales but not the people who actually fix things. Classic.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>Andrew Brown</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/unpopular-opinion-the-support-ticket-response-time-has-gotten-worse-this-year/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: Deploying the agent via Intune with conditional policies.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/walkthrough-deploying-the-agent-via-intune-with-conditional-policies/</link>
                        <pubDate>Tue, 21 Jul 2026 11:08:16 +0000</pubDate>
                        <description><![CDATA[Deployed Sophos Intercept X via Intune last week. Standard silent install with conditional access policies. Posting the configs for reference.

Main steps:
* Created two groups: `All_Devices...]]></description>
                        <content:encoded><![CDATA[Deployed Sophos Intercept X via Intune last week. Standard silent install with conditional access policies. Posting the configs for reference.

Main steps:
* Created two groups: `All_Devices` and `Compliant_Devices`.
* Used the Windows app (Win32) packaging method. Key install command:
```
SophosInstall.exe --quiet --installpath="C:Program FilesSophos"
```
* Assigned the app to `All_Devices`.
* Configured a compliance policy (encryption, firewall on, etc.) and assigned to `All_Devices`.
* Set a conditional access policy requiring device compliance for corporate apps. Targets `Compliant_Devices`.

The chain: Device installs agent &gt; becomes compliant &gt; moves to `Compliant_Devices` group &gt; gets access.

Pitfall: The initial sync delay between Intune compliance state and Azure AD group membership can block access for up to an hour. Plan for it.

- bench_beast]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>bench_beast</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/walkthrough-deploying-the-agent-via-intune-with-conditional-policies/</guid>
                    </item>
				                    <item>
                        <title>Help: Agent install fails on Windows Server 2012 R2 with a cryptic error.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/help-agent-install-fails-on-windows-server-2012-r2-with-a-cryptic-error/</link>
                        <pubDate>Tue, 21 Jul 2026 10:26:16 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;m hitting a wall trying to deploy Sophos Intercept X to a few remaining Windows Server 2012 R2 instances. The installer fails consistently with an error that doesn&#039;t point me ...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I'm hitting a wall trying to deploy Sophos Intercept X to a few remaining Windows Server 2012 R2 instances. The installer fails consistently with an error that doesn't point me to a clear solution.

The error in the Sophos installation logs is:
```
Error: 0x80070643 - Fatal error during installation.
```
The `SophosInstall.log` shows a bit more context just before the failure:
```
 Running installer action: InstallSophosCore
 Failed to execute installer action: InstallSophosCore. Exit code: -2147023293
```

Things I've already verified:
* The servers are fully updated on Windows Update.
* There's ample disk space and memory.
* No other AV software is present (we did a clean sweep).
* I've tried the standalone installer downloaded directly from the Sophos Central console, as well as the deployment package.
* Temporarily disabled Windows Defender via Group Policy before the install attempt.

Has anyone else encountered this specific scenario on Server 2012 R2? I'm wondering if there's a specific system component or prerequisite (like a certain C++ runtime or .NET version) that might be missing or need a repair, but the logs aren't helping.

My next step is to run the installer with verbose logging, but if someone has already cracked this nut, I'd appreciate the pointer. I'm also curious if this is a known issue that might require a specific installer version or command-line switch.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>Jane I.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/help-agent-install-fails-on-windows-server-2012-r2-with-a-cryptic-error/</guid>
                    </item>
				                    <item>
                        <title>Sophos Intercept X after 12 months - honest review from a sysadmin</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/sophos-intercept-x-after-12-months-honest-review-from-a-sysadmin/</link>
                        <pubDate>Tue, 21 Jul 2026 10:08:15 +0000</pubDate>
                        <description><![CDATA[Having now managed Sophos Intercept X across a fleet of just over 200 endpoints for a full year, I wanted to share some grounded observations. Our environment is a typical B2B mix of enginee...]]></description>
                        <content:encoded><![CDATA[Having now managed Sophos Intercept X across a fleet of just over 200 endpoints for a full year, I wanted to share some grounded observations. Our environment is a typical B2B mix of engineering workstations, sales laptops, and a few on-prem servers. We were drawn to Intercept X for its consolidated EDR and anti-ransomware promises, moving from a more basic AV solution.

The deployment and initial policy configuration were relatively smooth, which is a significant plus. The deep learning malware detection has been impressively accurate, with very few false positives in our daily workflow. The CryptoGuard component for ransomware has also been flawless in our testing and the one real-world attempted encryption event we experienced. Where I've spent more time than anticipated is tuning the exploit prevention modules. Some legacy applications required careful exception rules, which, while manageable, added to the administrative overhead.

My primary critique lies in the console experience. While powerful, the Central dashboard can feel cluttered, and finding specific telemetry sometimes requires more clicks than I'd like. The shift from alerts to "synchronized security" events with other Sophos products is logical, but it does create a learning curve. I also find the licensing model, while all-inclusive, can become a significant line item for larger deployments, so continuous evaluation of ROI is necessary.

Overall, it's a robust and highly effective platform that delivers on its core security promises. The operational reality, however, involves accepting some interface complexity and ensuring you have the bandwidth for proper policy management. I'm curious to hear from others who have been on this platform for a similar duration—have your experiences aligned, and how have you optimized the management overhead?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>David S</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/sophos-intercept-x-after-12-months-honest-review-from-a-sysadmin/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: How we validated the ransomware rollback feature actually works.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/step-by-step-how-we-validated-the-ransomware-rollback-feature-actually-works/</link>
                        <pubDate>Tue, 21 Jul 2026 07:48:54 +0000</pubDate>
                        <description><![CDATA[After years of analyzing database transaction logs and recovery mechanisms, I&#039;ve developed a healthy skepticism toward vendor claims, especially in the security space. A &quot;ransomware rollback...]]></description>
                        <content:encoded><![CDATA[After years of analyzing database transaction logs and recovery mechanisms, I've developed a healthy skepticism toward vendor claims, especially in the security space. A "ransomware rollback" feature sounds compelling in a datasheet, but its real-world efficacy under duress is what matters. When my organization evaluated Sophos Intercept X, we treated this claim not as a given, but as a hypothesis to be tested under controlled conditions. Our validation process was methodical, drawing parallels to testing a database's Point-in-Time Recovery (PITR) capability.

We constructed an isolated test environment, mirroring a critical but non-production server setup. The core components were:
*   A Windows Server 2019 VM, acting as the "target."
*   A representative sample dataset: a live copy of a mid-sized PostgreSQL database (using `pg_basebackup`), alongside a directory of standard office documents and PDFs.
*   Intercept X installed with default recommended policies, plus the "CryptoGuard" component enabled.
*   A separate attacker VM, housing a curated set of live ransomware binaries (e.g., Mimikatz, a locked-down variant of Ryuk) obtained from controlled, legitimate threat repositories.

The test procedure was executed in distinct phases:

**Phase 1: Baseline &amp; Tamper Protection**
We first established a known-good restore point. Intercept X's own "Tamper Protection" password was documented, and a system snapshot was taken at the infrastructure level as an ultimate fallback.

**Phase 2: Simulated Attack Execution**
1.  On the attacker VM, we initiated a simulated phishing payload that dropped and executed the ransomware binary on the target VM via a mapped network drive.
2.  We observed the ransomware's behavior: rapid file encryption, extension appending, and the generation of ransom notes.
3.  We allowed the process to continue until approximately 60% of the test dataset was visibly encrypted (confirmed by rapid checksum changes monitored via a pre-run `md5deep` inventory) before manually intervening.

**Phase 3: Rollback Trigger &amp; Analysis**
1.  On the target VM, we opened the Intercept X management console and navigated to the "Security Events" log. The ransomware activity was correctly flagged as "Malicious Activity."
2.  Within the event details, the "Rollback" button was available. Clicking it initiated the process.
3.  The console provided a status indicator. Upon completion, we were presented with a detailed report listing the files that were attempted to be modified and their restoration status.

**Critical Findings &amp; Verification:**
*   **File Integrity:** All encrypted database files (`base/16384/*.dat`), PostgreSQL control files, and documents were reverted to their pre-attack state. Verification was performed by comparing `pg_checksums` on the data directory and successfully starting the PostgreSQL service, followed by a `SELECT * FROM pg_database;` to confirm consistency.
*   **Rollback Scope:** The restoration was not a full-system reversion. Windows system files and logs that were altered during the attack remained in their post-attack state, which is logically sound. The feature specifically targeted the user data files impacted by the malicious process.
*   **Performance Impact:** The rollback operation for our ~50GB test dataset completed in approximately 8 minutes. This is comparable to a targeted file-level restore from a modern backup appliance but is inherently faster than a full VM restore.
*   **Limitation Observed:** In one test iteration where the ransomware process was terminated by the OS *before* Intercept X's detection could fully categorize it, the rollback option was not available for that specific event. This underscores the importance of the detection engine's role as the trigger; it's not a continuous data protection (CDP) journaling system like some database storage engines provide.

In conclusion, from a data integrity perspective, the rollback feature functioned as advertised *when the malicious activity was cleanly detected and stopped by the Intercept X engine*. It effectively uses a file system filter driver to maintain a cache of clean file data, analogous to a journaling file system's recovery mechanism. However, it is not a substitute for a robust, segmented, and tested backup regimen, such as the `pg_basebackup` and WAL archiving strategy we employ for critical PostgreSQL instances. It serves as a highly effective last-line, rapid-response recovery layer for a specific class of events, reducing the Mean Time to Recovery (MTTR) from hours to minutes for a localized attack.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>db_diver</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/step-by-step-how-we-validated-the-ransomware-rollback-feature-actually-works/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the Intercept X for Mobile add-on? Is it necessary for BYOD policy?</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/thoughts-on-the-intercept-x-for-mobile-add-on-is-it-necessary-for-byod-policy/</link>
                        <pubDate>Tue, 21 Jul 2026 05:39:39 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been knee-deep in evaluating our endpoint security stack, and we&#039;re a heavy Sophos shop. We&#039;ve got Intercept X Advanced running beautifully on all our corporate-managed en...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been knee-deep in evaluating our endpoint security stack, and we're a heavy Sophos shop. We've got Intercept X Advanced running beautifully on all our corporate-managed endpoints. The reporting in the Central dashboard is solid, and the EDR features have been a lifesaver a couple of times. &#x1f6e1;&#xfe0f;

Now, we're formalizing a BYOD (Bring Your Own Device) policy for a segment of our team. The "Intercept X for Mobile" add-on immediately came up. The sales team is, of course, advocating for it, but I'm trying to cut through the marketing and think about it from an integration and practical automation standpoint. Is it *necessary*, or is it overkill for personal devices that primarily just access email and a few SaaS apps via secure tunnels?

Here’s my breakdown of considerations, and I'd love your real-world experiences:

*   **The API &amp; Management Angle:** One huge pro for me is having everything in one console. If the mobile add-on feeds into the same Sophos Central APIs, that means I can potentially automate alert responses and pull consolidated reports across *all* device types. Without it, mobile is a blind spot in our automated workflows.
*   **Threat Landscape for Mobile:** We're not talking about developers compiling code on their phones. It's mostly phishing via email, malicious links in messages, and potentially sketchy apps. Does Intercept X for Mobile provide a tangible layer of protection against these that justifies the per-user cost, especially when we already have strong mobile application management (MAM) and conditional access via our IDP?
*   **The "Low-Code" Alternative Thought:** Could similar security outcomes be achieved by stitching together other services? For example:
    *   Use Microsoft Intune (or similar) for compliance checks and app management.
    *   Set up a webhook from our email security gateway to automatically quarantine emails if a user clicks a reported malicious link on *any* device.
    *   Rely more heavily on network-level zero trust (ZTA) rather than relying on an agent on the endpoint itself.
*   **Pricing &amp; Value:** It's an additional cost per user, obviously. For those who have it, do the features—like the anti-phishing scanner for SMS and apps, or the Wi-Fi security check—actually get used and valued by employees, or are they just immediately disabled as "annoying"?

My gut tells me that for a strict BYOD policy where access is already gated by strong authentication and device compliance checks, the add-on might be redundant. But I hate having gaps in my event logs and automation! If the agent provides unique, actionable telemetry that I can feed into our other systems, that might swing it.

Has anyone done a deep integration or built workflows around the mobile threat data? Or decided against it and found a better, more API-driven way to cover that attack surface?

Happy integrating,
Bob]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>Bob Wilson</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/thoughts-on-the-intercept-x-for-mobile-add-on-is-it-necessary-for-byod-policy/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made: A comparison of detection times vs. our old AV solution.</title>
                        <link>https://communities.stackinsight.net/community/cyber-sophos-intercept-x/check-out-what-i-made-a-comparison-of-detection-times-vs-our-old-av-solution/</link>
                        <pubDate>Tue, 21 Jul 2026 03:04:39 +0000</pubDate>
                        <description><![CDATA[Just migrated our help desk team from a basic antivirus to Sophos Intercept X. Wanted to share a quick comparison I made on detection times for common threats.

We used a set of test EICAR f...]]></description>
                        <content:encoded><![CDATA[Just migrated our help desk team from a basic antivirus to Sophos Intercept X. Wanted to share a quick comparison I made on detection times for common threats.

We used a set of test EICAR files and some recent phishing payloads we'd logged. The old AV averaged 8-12 minutes to flag and isolate. Intercept X caught them in under 2 minutes, most in under 60 seconds. The difference in automated response was significant. Has anyone else measured this kind of operational impact, especially in a SaaS support environment?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-sophos-intercept-x/">Sophos Intercept X Reviews</category>                        <dc:creator>JacksonM</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-sophos-intercept-x/check-out-what-i-made-a-comparison-of-detection-times-vs-our-old-av-solution/</guid>
                    </item>
							        </channel>
        </rss>
		