Issues with Input Focus After macOS 26.1 Update

Update on AdminByRequest Side:

We've now implemented a fix which doesn't require modifications to a policy-file. Below a complete step-by-step procedure to remediate the issue:

1. Download ABR v5.1.2 for macOS from the Download section in your portal

2. On affected devices, either deploy the client via an endpoint manager, or install it manually as a true administrator.

3. In the test-portal located at https://test.adminbyrequest.com/ (please note, you will need to sign in with credentials as to not get redirected to the production-site) browse to Mac Settings (or potential sub-setting) -> Lockdown -> Admin Rights.

4. Enable Disable in-app updaters.

5. Finally, invoke About ... from the ABR taskbar icon on affected devices.

Please be aware that enabling the setting will prevent some in-app updaters from gaining privileges. These will instead need to be handled via, for example, an Admin Session.

I´ve implemented this solution above - and that worked like a charm!

Hopefully this helps other in the meantime!

Seems like a known issue out there with macOS 26.1 regarding apples security changes with "SecurityAgent": (a reply from AdminByRequest for example here): Thanks Wesley for that information

Here is a brief update on the situation:

The behaviour is caused by a change in macOS 26.1 involving Apple’s SecurityAgent service. When certain system-level authorization events occur, macOS may momentarily shift window focus, even though no dialog is shown. This results in the cursor jumping out of fields or applications losing focus.

This is not specific to Admin By Request. Multiple well-known security and device-management vendors are reporting the same issue, and there are active discussions on Apple’s Developer Forums and community channels confirming identical symptoms.

Current status

We have reproduced the issue consistently on macOS 26.1

It is seen most frequently on MDM-enrolled devices

We have reported the behaviour and log data to Apple

Apple has not yet released a fix

Other vendors in the industry are experiencing the same issue

Workaround / Temporary Mitigation

We are testing a patch that allows organisations to disable the specific OS authorization event that triggers this behaviour. This avoids the focus-loss issue without lowering endpoint security. Once Apple corrects the underlying macOS behaviour, we will re-enable full integration automatically.

We will continue to monitor Apple’s updates, and we will let you know as soon as a confirmed fix or improvement becomes available.

There are some investigations from AdminByRequest on that case. What they told me to do:

As part of the investigative process for identifying the root cause of the window focus problem some users experience after upgrading to MacOS 26.1, we believe that we’ve identified the cause of the issue.

The issue is linked to the com.apple.ServiceManagement.daemons.modify right which Admin By Request leverages to monitor e.g. in-app updates that might require privileges.

While engaging Apple etc. to get to the root cause of the changes made to MacOS 26.1 we’ve created a temporary workaround that will allow customers to disable the com.apple.ServiceManagement.daemons.modify right for Admin By Request via a policy. This workaround is made available via the Admin By Request Mac 5.1.2 update and will allow disabling the right by setting the following policy:

{
  "DisableDaemonsModifyHook": 1
}

Please be aware that setting this policy will prevent some in-app updaters from gaining privileges. These will instead need to be handled via for example an admin session.

While we realize that this is a temporary workaround until the full scope of the MacOS 26.1 changes are known and a permanent solution can be implemented, this solution could help end users get past the window focus loss issue here and now.

If you experience any issues with the policy - or if the window focus loss problem persists - please reach out to our support team.

What i´ve tried was a .mobileconfig in Intune which looks like the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPEplist PUBLIC "-//Apple//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plistversion="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadDescription</key>
            <string>Disables the com.apple.ServiceManagement.daemons.modify right for Admin By Request</string>
            <key>PayloadDisplayName</key>
            <string>Admin By Request - Daemons Modify Hook Workaround</string>
            <key>PayloadIdentifier</key>
            <string>com.fasttracksoftware.adminbyrequest.workaround</string>
            <key>PayloadOrganization</key>
            <string>AdminByRequest</string>
            <key>PayloadType</key>
            <string>com.fasttracksoftware.adminbyrequest</string>
            <key>PayloadUUID</key>
            <string>A1B2C3D4-E5F6-7890-ABCD-EF1234567890</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>DisableDaemonsModifyHook</key>
            <integer>1</integer>
        </dict>
    </array>
    <key>PayloadDescription</key>
    <string>This profile disables the com.apple.ServiceManagement.daemons.modify right for Admin By Request as a workaround for macOS 26.1 changes</string>
    <key>PayloadDisplayName</key>
    <string>Admin By Request - Daemons Modify Hook Workaround</string>
    <key>PayloadIdentifier</key>
    <string>com.fasttracksoftware.adminbyrequest.workaround</string>
    <key>PayloadOrganization</key>
    <string>AdminByRequest</string>
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>F1E2D3C4-B5A6-9870-1234-567890ABCDEF</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

Sadly the support said:

By closer examination it does not look like your configuration writes anything to /Library/Application Support/Admin By Request/adminbyrequest.policy but just seem to be a configuration which our client does not read. I'm not an expert in Intune or how it works in deploying to Mac unfortunately, but it seems like it might not be a mobileconfig afterall. Sorry to have guided you in the wrong direction.

I completely understand this issue is disruptive, to put it mildly. I should have some new information on the issue soon, and I will update you instantly.

Therefore my workaround was uninstalling ABR for the moment until they get a fix implemented.