Thanks @const_void for your response. I was looking for a technical way for MDM providers to implement this policy to control whether users are allowed to disable SIP or not. I looked through Apple's list here and could not find anything about controlling SIP. So wanted to understand whether it's even possible or not. Major MDM providers like JAMF and Intune, do provide an option to create smart groups based on whether SIP is enabled or not. But is there a way to prevent users from disabling SIP. In certain cases, we can not block access to users because some of them are education bodies who control the machines via MDM, not just employees.

Thank you for your help Quinn. It would be great if Security APIs could also mention the extension causing the failure, in error message. Unable to parse known extension; is not very clear error, IMO.

Thank you for your response Quinn. Few questions about PreLoginAgents: What's the best way to enable or disable them? For example if a feature flag is enabled in thin client, we would want to display the PreLoginAgent and not otherwise. One way I could think of is to place and remove the PreLoginAgent from /Library/PrivilegedHelperTools/ directory based on feature flag. Is there any better way? Can we make this decision inside the agent? Can a PreLoginAgent make an XPC connection to a LaunchDaemon? Can a PreLoginAgent read files from root directories like /Library/Application Support/?

One important point I just noticed is that PreLoginAgents do not run on machine start/restart when FileVault is enabled on the machine (which is quite common). This breaks the requirement of displaying the UI on login screen in most of cases. People usually either Lock Screen or Restart machine and PreLoginAgent cannot be displayed in either of these cases. Is there a better way? Should we instead use SFAuthorizationPluginView to display this UI beside the macOS login screen?

Thank you Quinn for the detailed answer. Few more questions: On a machine with FileVault enabled, on reboot, what happens to an authorization plugin whose mechanism is added to authorization db before loginwindow:login? Would the plugin still be invoked after pre-boot login? Would login window appear again after the plugin has finished since loginwindow:login is listed after the plugin? How does pre-boot login work for users who need authentication with AD server? Would they be prompted for AD login again after pre-boot login? (Assuming no third party authorization plugin exists)