Actually it does work on home versions as well and does not require gpedit.msc to import or create the .reg as shown in my example.....I assume that means you didn't bother to test it /sigh It is applied the same way older versions of "CryptoPrevent" were, directly in the registry policy area...only this one is firewall related instead of SRP....... My example (see 1 again) is not meant to thwart network administrators or those who actually connect to a domain or otherwise use group policy. I believe I covered this aspect in the original post where I explicitly said (See underlined): "This would leave only SYSTEM with write abilities and allow both the WFC Service (wfcs, which already runs as NT AUTHORITY\SYSTEM) and (if the user or an Admin uses it locally) Group Policy to be applied/edited properly on Pro+ systems while still removing the ability of a .reg file bypass (as Admin) like shown in my example." I do not dispute this and I also covered it in the original post where I said: "I did this with admin rights like a majority of software installers also require anyway." No arguments there but my suggestion retains the ability to apply more restricted permissions (simply in a different location that the Windows Firewall already processes [and trumps SharedAccess with "AllowLocalPolicyMerge"=dword:00000000 set]) yet prevents the issues caused in scenarios with the current 'new' version of secure rules especially with (but not limited to) the latest version of Windows (eg 10) while also preventing those rules from being used! It's win-win....so I'm honestly flabbergasted I've had to argue this point even once! I can't argue here but as my other post said, I was able to do all this with just .bat files and other preexisting programs found in Windows. While I surely wouldn't suggest you do it the same way I did for my tests I must say I find this argument to be...lacking... I refer you back to point 1. Yes it does....add the rules and .reg I pasted in the original post and reboot. See for yourself as you really should have before dismissing it all! I did not encounter any new issues and it solved all the problems in my (limited) test. What is it you think isn't solved? The point with the steps was to keep the rules which are actually applied (in the policy area) until something needs to be added or changed via WFC. The short span in which you would alter permissions in SharedAccess, starting by temporarily setting permissions as they are now followed by clearing any existing rules there that 'might' have been created outside WFC then copy the actual rules from the policy area back to the SharedAccess location (so you can use existing APIs) and create or change a rule before copying them all and restoring them back to defaults should be small enough to avoid the current issues but have the exact same level of security as the current 'new' secure rules....plus a bit more as it prevents the simple .reg bypass which WFC is currently (and as you so kindly pointed out, also previously) blind to. So simply refresh the firewall after every edit, creation, or deletion? What's the big deal? That's what I did with my example and gpupdate /force... It allows installers, including UWP installs/updates, Windows Defender and Windows Update or whatever else might deign to try and add a firewall rule to do so and succeed in creation of the rule under SharedAccess yet still prevent the rule(s) from actually being applied. If you didn't get that I see why you argued with it all. I suggest you play/test with gpedit.msc and the firewall policy area (via import/export even on home) a bit! Instead only those rules which WFC (or an admin via group policy) add would be applied so long as the proper keys are set and 'secured'. It really wasn't my intention to argue anything but I must say I am getting frustrated at how no one seems to grasp the points. I actually hoped I had made my goal and methods clear but you and others here seem to have completely missed both so I figured I'd give it one more go by responding to your points.