{"id":34998,"date":"2026-06-29T23:18:58","date_gmt":"2026-06-29T23:18:58","guid":{"rendered":"https:\/\/www.adminbyrequest.com\/en\/?p=34998"},"modified":"2026-06-29T23:20:08","modified_gmt":"2026-06-29T23:20:08","slug":"whats-new-in-admin-by-request-for-macos-5-3","status":"publish","type":"post","link":"https:\/\/www.adminbyrequest.com\/en\/blogs\/whats-new-in-admin-by-request-for-macos-5-3","title":{"rendered":"What’s New in Admin By Request for macOS 5.3"},"content":{"rendered":"\n

Admin By Request for macOS 5.3 is out now, with deeper privilege control over macOS System Settings, app blocking, app uninstall handling, passwordless Secure Remote Access, Jamf integration improvements, and a few other additions worth covering.<\/p>\n\n\n\n

More Granular Privilege Control Over macOS<\/h2>\n\n\n\n

The main theme in 5.3 is giving you finer control over what standard users can do on their Macs without handing over full admin rights. macOS has historically made this an all-or-nothing situation, and we’re chipping away at that.<\/p>\n\n\n\n

System Settings Pre-Approval<\/strong> lets standard users access selected System Settings panes through Admin By Request authentication, without being granted a full admin session. The portal now supports a wider set of panes, including System Extensions, Time Machine, Date & Time, Energy Saver, Printing, and System Updates. When a user opens a pre-approved pane, the standard macOS admin prompt is intercepted and the change is authorized in place, with every approved action logged at pane-level detail so you can see exactly what was changed and by whom.<\/p>\n\n\n\n

This covers a lot of everyday tasks. Setting up a printer, adjusting energy settings, or installing a system update no longer needs a helpdesk ticket or a temporary admin promotion. Your existing lockdown behavior stays intact too, so any panes you’ve left toggled off remain hidden during an admin session. And if you’re running MDM configuration profiles, those take precedence: anything restricted by MDM stays restricted, so you can mix MDM-enforced controls with Admin By Request pre-approval without them stepping on each other.<\/p>\n\n\n\n

App Uninstall from Applications<\/strong> brings the same logic to removing software. Standard users can now uninstall eligible apps from \/Applications through Admin By Request authentication, closing a gap from 5.1 (which already allowed installs from \/Applications but still required a full admin session to remove an app). Protected, restricted, and managed apps stay protected, with removal continuing to require native administrator credentials, so business-critical software can’t be cleared out through this path. Both Finder-based installs and uninstalls now route through Admin By Request, giving you a single authorization path for app lifecycle changes from \/Applications.<\/p>\n\n\n\n

App Blocking for macOS<\/strong> rounds out the privilege control story from the other direction, bringing parity with the App Blocking capability that’s been on Windows for a while. You can block macOS apps by checksum, Team ID, or Bundle ID. Blocked apps won’t launch, and users get a notification explaining why. You can also block the Mac App Store for standard users while keeping it available to administrators, which is a common ask from organizations trying to lock down unmanaged software installs. Blocking rules can be version-ranged as well (more on that below), so you can target specific vulnerable builds rather than blocking an app outright.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Smarter App Pre-Approval<\/h2>\n\n\n\n

Two improvements here that make pre-approval rules less of a blunt instrument:<\/p>\n\n\n\n

Bundle ID App Pre-Approval<\/strong> lets you approve a specific application without giving the green light to every app from the same vendor. Pre-approval already matched on Team ID, but Team ID covers everything a vendor signs. With Bundle ID matching, you can trust a single utility from a major vendor without trusting the rest of their catalog. Both identifiers show up together in audit log entries, so you can tie approvals back to specific apps rather than vendor groupings.<\/p>\n\n\n\n

Version-Based App Pre-Approval<\/strong> adds minimum and maximum version constraints to macOS pre-approval rules. This is useful when you want to allow a known-good version range but block anything older (with known vulnerabilities) or newer (untested in your environment). The same version bounds apply to App Blocking rules, so the control works in both directions. It’s handy for phased rollouts where only a tested version range should be allowed during a transition, and it brings Mac in line with the equivalent capability in the Windows 8.8 release.<\/p>\n\n\n\n

Passwordless Unattended Access for Mac<\/h2>\n\n\n\n

Our Secure Remote Access product now supports unattended sessions on macOS without a shared, pre-set password. Since macOS has no true passwordless login, a just-in-time local account is provisioned and one-time credentials are emailed to the admin when they click Remote from the inventory. The admin signs in with those credentials, and when the session ends (whether by logging out, disconnecting, or dropping the connection), the account is automatically signed out and cleared from the login screen so it can’t be reused by anyone with physical access to the Mac.<\/p>\n\n\n\n

This addresses one of the awkward realities of remote Mac administration: credentials had to live somewhere, and that “somewhere” was usually a security risk. With one-time credentials managed by the platform, that whole category of problem goes away.<\/p>\n\n\n\n

Jamf Group-Based Sub-Settings<\/h2>\n\n\n\n

If you’re managing Macs with Jamf Pro, this one’s for you. macOS sub-settings can now be targeted by Jamf computer group membership instead of being scoped manually inside Admin By Request, and both static and smart computer groups are supported. Build your groups in Jamf the way you already do, connect Jamf Pro to the portal, and use that membership to drive which sub-settings apply to which Macs.<\/p>\n\n\n\n

For organizations running Jamf as the primary MDM, this means less duplicated grouping work and a cleaner way to keep policies matched to the right devices.<\/p>\n\n\n\n

Under the Hood<\/h2>\n\n\n\n

The usual round of performance improvements, stability fixes, and small refinements throughout the agent and portal experience. Nothing dramatic, but every release tightens things up a little.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Closing the Cross-Platform Gap<\/h2>\n\n\n\n

If you’ve been following our recent Mac releases, you’ll notice a pattern. We’re working steadily to bring macOS feature parity in line with what Windows users have had for years. Version 5.2<\/a> brought Secure Remote Access to Mac, and 5.3 deepens privilege control while adding granular app governance that Mac admins have wanted for a long time. App blocking and version-ranged rules both close specific gaps between the Mac and Windows clients in this release.<\/p>\n\n\n\n

Whether your team is on Windows, macOS, or Linux, the privilege management experience should feel consistent across platforms, with policies and audit data managed from a single portal. Running different tools for different operating systems creates fragmented workflows and visibility gaps that attackers know how to find.<\/p>\n\n\n\n

Existing customers can grab 5.3 from the admin portal. If you’re new to Admin By Request and want to see how this works in your environment, book a demo<\/a> and we’ll walk you through it.<\/p>\n\n\n\n

Useful Resources for this Release:<\/h2>\n\n\n\n