XProtect Remediator has changed its behaviour

Since XProtect Remediator (XPR) went live during the summer of 2022, it has run daily sets of checks for known malware in macOS Catalina and later using its scanning modules. Those have been sufficiently regular and reliable that some of my apps, including Skint and SilentKnight, check that they’re occurring and report normal and healthy results. Just over a month ago, I provided a detailed account of XPR’s different types of scan, and how they are scheduled and dispatched in XPR version 149. Last week in XPR version 151, Apple changed all that, and Skint, SilentKnight and XProCheck may now show few scans and frequent warnings.

As Apple has never provided anything other than the vaguest of information about XPR, I have no idea whether this is the new normal, or the result of bugs. As XPR scans now vary greatly between different Macs, and run least on those with large numbers of Time Machine backups accessible, I’m inclined to suspect at least some of this is unintended behaviour.

XPR scans

There are still three types of timed scan:

a fast scan, com.apple.XProtect.PluginService.agent.fast.scan, performed at intervals of 6 hours (21600 seconds), and run when on battery;
a standard scan, com.apple.XProtect.PluginService.agent.scan, performed at intervals of 24 hours (86400 seconds), but not run when on battery;
a slow scan, com.apple.XProtect.PluginService.agent.slow.scan, performed at intervals of 7 days (604800 seconds), but not run when on battery.

In the standard scan, each of the scanning modules is run in turn, once using the agent version running as the current user, normally 501, and once using the daemon version as root, user 0.

Fast scans do run every six hours, but don’t currently include any of the scanning modules, so leave little trace in the log. They are also run soon after starting up and logging in as a user, where they’re referred to as a startup scan when run as root, and a login scan when run as the current user, usually 501.

As a slow scan is only run once a week, I still haven’t been able to observe one.

With XPR version 151 installed, you’re likely to see the following sets of scans after user login:

Paired startup and login scans, no scanning modules used, taking about 46 seconds for root and 9 seconds for user 501.
Timed low priority scans as root and user, using just the Eicar scanning module, and taking about 2 and 1 seconds respectively.
Timed standard scans as root and user using all the scanning modules, and taking around 175 seconds for root, and up to 600 seconds as user. These may be cancelled by the XP Timer firing, which kills the current scanning module and terminates that set of scans, leaving them incomplete.

Thereafter, every six hours a fresh fast scan is performed, and every 24 hours a standard scan is attempted, although the latter may be terminated without completing any scanning modules at all.

XP Timer termination

At varying times after the start of a standard scan running its sequence of scanning modules, they may be interrupted by the firing of the XP Timer, and you’ll see a sequence of entries in the log describing how that not only kills the current scanning module, but terminates the whole of that set of scans:
16.438 com.apple.XProtectFramework 34294 XP Timer fired, killing activity
16.438 com.apple.XProtectFramework 34784 Received SIGTERM, canceling running plugins then exiting
16.439 XProtectRemediatorAdload Cancellation handler called for reason: Dispatch recieved SIGTERM
16.442 XProtectRemediatorAdload {“caused_by”[], “execution_duration”:0.0002809762954711914, “status_message”:”PluginCanceled”, “status_code”:30}

It’s that status_message and status_code that is detected by XProCheck, SilentKnight and Skint, and reported there as a warning.

16.450 com.apple.XProtectFramework Finished system scan, ran as 501
16.451 com.apple.duetactivityscheduler COMPLETED <_DASActivity: “501:com.apple.XProtect.PluginService.agent.scan:BD32B7”, Utility, 60s, [09/03/2025, 07:39:13 – 10/03/2025, 07:39:13], Started at 09/03/2025, 19:52:35, Group: com.apple.dasd.default, Intensive: CPU Disk, PID: 2254>
16.453 com.apple.xpc.activity Rescheduling: com.apple.XProtect.PluginService.agent.scan (0x653344140)
16.457 com.apple.duetactivityscheduler Completed <private>, ran for 9.7 mins, total runtime 9.7 mins

The next daily standard set of scans are then submitted to DAS for rescheduling, to be run in about 24 hours:
16.465 com.apple.duetactivityscheduler Submitted: 501:com.apple.XProtect.PluginService.agent.scan:15B497 at priority 30 with interval 86400 (Mon Mar 10 07:52:34 2025 – Tue Mar 11 07:39:13 2025)

Although referred to as the XP Timer, times when it will fire range widely, from a few seconds to nearly ten minutes, and there’s no indication of how that is determined.

Effects

XPR checks now differ greatly between Macs. Most basic systems running from their internal SSD with a minimum of external storage, with just a modest set of Time Machine backups, still appear to complete standard scans normally, as they did in previous versions of XPR.

Macs with multiple external disks and long series of Time Machine backups may now complete few if any standard scans. Instead, most or all of them are terminated prematurely by the XP Timer, so triggering warnings in XProCheck, SilentKnight and Skint.

If you wish to run a set of XPR scans manually, then you still can, either in XProCheck or by running the XProtect app yourself. Those are run as the current user, not as root, but may be sufficient to restore your confidence in XPR’s protection.

This leaves me with a dilemma: should those apps suppress those warnings and tell you that everything is fine with XPR’s checks, or should they continue to report them? Given all the problems with XProtect updates in Sequoia, would it be simplest just to abandon my attempts to check anything in macOS security? Are these bugs, and should they be reported to Apple, or is this the new normal we have to look forward to for the future?