Sophos Endpoint Blocking updates

Looks like its performing permissions management over the softwareupdate binary. You will need to work with the vendor on this, even if they dont want to work with you. The application should be auto promoting this binary, and not prompting for anything so a rule is likely configured wrong.

We do not use Sophos but have a similar tool that handles point of time permissions management, and all kinds of rules have to be setup or it will break all kinds of stuff you dont want to break.

How are you triggering the prompt? Ive not seen that before

Just ran into this same issue on one of our endpoints. 

We're looking into two possibilities right now: 

1. As pointed out, the fact the softwareupdate process is calling a Group of "SophosEndpoint" that contained the primary user of our device (but deactivated) suggests it's doing something it 'aught not to be. 
2. Can't see a single thing on the Config Profile from v1.1 to v1.2 that could contribute to that behavior, as a code issue being run by the auto-updater seems far more likely, but we're updating the affected machines to rule it out. 

I'll update this is we come up with an answer (or to rule these out). 

@tycollins @s-mcc  anyone find a solution to this? I periodically receive the same error on Ventura.

@SCCM Initiating an OS upgrade from Settings will cause it:

Currently experiencing the same issue. Sophos doesn't have any solution. I even tried uninstalling Sophos and I still get the prompt with SophosEndpoint as the username.

I have a pending solution update to this:

We confirmed that all of these errors were related to the lack of volume ownership on the part of our affected users. 

Working with Sophos support, they became dead set on the cause being "Installation of Sophos before user login". 

Using the kb as reference (Use secure token, bootstrap token, and volume ownership in deployments - Apple Support) we created an extension attribute to hunt through our machines and report back any machines that had tokens assigned to the "_sophos" account. That list lined up with the machine errors we were seeing, (and some machines we had not yet).

We've broken out in to two phases for remediation:

1. Even though the logistics of how Sophos installed post-enrollment but pre-login are not clear, we have added a delay into our Sophos installation polices. It was one of the few apps allowed to install outside of a dep-notify/swiftDialog initial configurations during setup (check-in trigger), and we added it to an "enrollment complete" delayed smart group to ensure even pausing at the Setup Assistant would not allow a background action. Since this change no more affected machines have appeared.
2. Using the admin account created via our Pre-stage Enrollment, we're repairing the token issues for the affected users. So far that seems to be working, but I'm still waiting on full confirmation from my in-field team.

We use CyberArk EPM, and last month I noticed if it installs before any user logs it EPM force generates macOS's Secure Token. Of course, EPM has no way to pass that secure token to a user. The vendor was as useless as you would expect. We wound up delaying the install of EPM until after Disk Encryption is enabled, that way the end user would have already logged in and they get a Secure Token and Volume Ownership before EPM can go and mess things up. I'd wager Sophos is doing the same thing.

@s-mcc Can you provide the remediation steps for repairing the token?

can you provide instructions on how to repair the token issues for affected users?

I wanted to add an end tag to this discussion to say: Don't attempt it. 

The remediation attempts got so convoluted, that we abandoned them. Since ensuring that Sophos installation is either handled automatically after a delay from enrollment or white gloved by installation teams post login, this issue has disappeared from our management space. 

We opted to start over (wipe and ADE) with all affected machines in the name of reliability and brevity. The answer from both vendor and Apple support has amounted to "that shouldn't happen" so I would not hold my breath on a solution.