Here's a better one: if Cylance was a good security solution, then it would be capable of updating any components critical to the security of my environment without compromising the security. Let's consider the scenario of the device drivers belonging to Cylance being updated. Now, obviously, the process creation filtering (and if they support normal real-time protection on the file system, such as for file write/read or others) is going to be filtered out from kernel-mode via callbacks (which would be the smart and documented thing to do). But wait... the device drivers need to be updated! Does this mean the system will be vulnerable? No. The smart move would be for the update to be handled on reboot, and thus you'd not be vulnerable whilst a device driver component of Cylance is being updated.
Let's consider the scenario of a real-time protection component based in user-mode and worked by the user-mode service under the SYSTEM account being updated (if this is valid for Cylance in question). Now, usually, the service of a security solution is going to be involved with the filtering procedures (and sometimes cloud integration) but it is not rare for the functionality for all of this to be contained within external libraries (e.g. Dynamic Link Libraries) which the user-mode service will load and make use of. In these scenarios, when the user-mode service receives a scan request, the smart move would be to keep the operation pending until the component being used by the user-mode service which has involvement with the scan operation has been re-loaded post-update, instead of just letting it through blindly because an update was going ahead. What if the actual image on disk of the user-mode service process needs to be updated? Smart move would be to do it on reboot, so the user won't be left vulnerable during that update. I'm not saying Cylance works in the way described above. I don't know how Cylance works because I haven't used it yet. I'm just reading to what others have said on this thread about it so far and am interested in it. But there we have it... an update doesn't necessarily have to leave the user vulnerable during the update procedure.