SMB with mandated third-party remote-support software (ScreenConnect): full baseline + per-machine exceptions, or a reduced uniformly-automatable baseline — which do you recommend?

[ShaheedFazal]

Context, upfront and honestly: I'm a small business owner, not a security engineer. I run a small number of managed Windows 11 endpoints. I want them as secure as I can realistically sustain, which is why I'm using Harden System Security (Business intent). I used an AI assistant (Claude) to diagnose the problem below, so the technical detail is deeper than I could produce alone — please don't assume expertise I don't have, and correct anything I've got wrong. I'm asking for direction, not a bug fix.

Hard constraint: Several of my external software/service providers use ConnectWise ScreenConnect as their remote-support tool to connect in and assist me when I have issues with their products. It's their support channel, not management software I control — so "don't run ScreenConnect" isn't available to me. It has to be able to run on every machine.

The conflict: After applying the baseline, both ScreenConnect executables (the user-mode client and ScreenConnect.ClientService.exe) crash at startup:

System.ComponentModel.Win32Exception (0x80004005): NativeErrorCode 5 - Access is denied
- while executing WindowsNative.SetProcessMitigationPolicy(...)
   at ScreenConnect.WindowsExtensions.FixupProcess()
   at ScreenConnect.Program.Main(String[] args)

ScreenConnect calls SetProcessMitigationPolicy on itself during init and the call is denied. I've already worked through (and ruled out) the simpler layers, with help:

• App's Add Exclusions → Process for both executables — no effect
• System-wide Mandatory ASLR (MitigationOptions) — cleared, confirmed zeroed after reboot
• Per-exe Set-ProcessMitigation -Disable ForceRelocateImages (per your Git wiki page) — applied, but Override stayed False
• App's Mandatory ASLR item disabled via the UI — error persisted
• No related scheduled tasks; no Exploit Guard policy keys
• Root cause appears to be VBS/HVCI + enforced code integrity: Win32_DeviceGuard shows CodeIntegrityPolicyEnforcementStatus 2, SecurityServicesRunning {1,2,5,7}; HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard enforcing VBS/HVCI; Smart App Control Off

I've read #1049 (Dynamic Code Security / 3114) and #1115 (Exploit Protection best practices). #1049 looks like the closest precedent — your guidance there was to keep the protection enabled and create targeted App Control rules for the offending files via AppControl Manager. My case differs slightly: the block is a SetProcessMitigationPolicy denial under HVCI rather than a 3114 dynamic-code event, so I'm unsure the same supplemental approach applies.

My actual question — two paths, and I'd value your steer on which is right for someone in my position:

Option 1 — keep the full baseline, exempt ScreenConnect surgically. Is there a supported method to make ScreenConnect coexist with HVCI/enforced code integrity (e.g. an AppControl Manager supplemental for its binaries, or similar) that is realistic for an SMB with no dedicated security staff to maintain — including when ScreenConnect or the baseline updates? If it can be done without ongoing per-machine hand-maintenance, I'd prefer it.

Option 2 — a reduced but uniformly-automatable baseline. If Option 1 realistically requires per-machine exception management I can't sustain, which categories/intent would you recommend I exclude (the VBS/HVCI + code-integrity layer? mandatory ASLR?) to get a single, automatable config I can deploy identically to every endpoint and still retain the bulk of the protection (Defender, ASR, SmartScreen, BitLocker, firewall, audit, TLS, UAC)? My priority is something I can apply consistently and reliably across all machines, because inconsistent hardening is its own risk.

Either answer is genuinely useful — I just want to make an informed, sustainable decision rather than keep guessing. Sanitised config export attached (machine name/username redacted; everything else verbatim). I am happy to PM you a few ScreenConnect codes for testing if it helps.
Uploading harden_config_sanitised.json…

Thank you for the project and for how thoroughly you engage here — it's the reason I'm asking rather than guessing.

[HotCakeX]

Hi, I'm always glad to help anyway i can. So let's see...this error

System.ComponentModel.Win32Exception (0x80004005): NativeErrorCode 5 - Access is denied
- while executing WindowsNative.SetProcessMitigationPolicy(...)
   at ScreenConnect.WindowsExtensions.FixupProcess()
   at ScreenConnect.Program.Main(String[] args)

Means the Screen Connect is failing to set process mitigations for its own process. It's something that processes can do early in their launch sequence to setup non-persistent protections for themselves. The error indicates a problem between the Screen Connect and the OS, most likely the way that program is using that function is problematic, can't tell more about it without seeing the source code of ScreenConnect and I don't really see why any security measure in the Harden System Security app could be related.

Also, there seems to be a tiny bit of confusion because AppControl Manager and Harden System Security are completely separate and you only mentioned that you applied the business device usage intent, but didn't deploy any App Control policies. We can exclude things from App Control policies but the security measures applied by the Harden System Security app don't usually have the ability to create exclusions.

You mentioned "Root cause appears to be VBS/HVCI + enforced code integrity" so that means if you remove security measures from the Device Guard category, Screen Connect will work fine?

Is there a supported method to make ScreenConnect coexist with HVCI/enforced code integrity?

If it's not compatible then i don't think so, i'm not aware of any method to create exclusions for HVCI/VBS, only kernel-mode drivers could have conflicts with them.

If Option 1 realistically requires per-machine exception management I can't sustain, which categories/intent would you recommend I exclude?

I recommend applying everything unless there is a reason not to apply a specific security measure in your environment. So if in this case the problem is HVCI then you can only undo/remove that specific security measure and keep everything else.

It'll be easier if you take a VM and test ScreenConnect on it with the security measures from the Harden System Security app until you find the item that is causing that error. Could do it on your physical system too, it's just VM is easier to rollback.

You can remove all security measures by clicking on the "Remove All" button in the Protect page after setting the preset to "Complete" (from the combobox) and restarting the system. Then you can apply them category by category and each time test ScreenConnect. That'll make it easy to identify what is causing that error in ScreenConnect.

[Harvester57]

Dumb question here, probably, but did you reboot after applying the Exploit Protection changes, and before testing the app ? Specifically, a reboot between these steps and the test is probably required:

• System-wide Mandatory ASLR (MitigationOptions) — cleared, confirmed zeroed after reboot
• Per-exe Set-ProcessMitigation -Disable ForceRelocateImages (per your Git wiki page) — applied, but Override stayed False
• App's Mandatory ASLR item disabled via the UI — error persisted