https://blogs.windows.com/msedgedev/2017/02/23/mitigating-ar...
Microsoft should apply these same restrictions to all UWP apps. Yes, that means banning JIT compilation, as Apple does on iOS. And desktop applications shouldn't be able to inject DLLs into UWP applications and system components.
On any platform, it makes sense to enforce code signing by default as a hardening measure, but some apps like browsers cannot operate without a JIT. So there needs to be some exception process - possibly requiring the use of a separate process for JIT compilation, as Edge now does. You don't want to end up like iOS where Safari is the only browser permitted on the platform.
I really wish they didn't. Banning JIT means banning alternative web browsers (with alternative JavaScript engines,) banning other languages that use a runtime with a JIT, and making it very difficult to write programs that need a JIT for performance, like video game emulators. Banning JIT outright like Apple does makes for a less useful computing platform. What's worse is that if certain operating-system components are allowed to break the rules (like the built-in JavaScript engine,) it locks you in to the vendor's implementation of these components. Imagine if you could only use the CLR and not the JVM on Windows. Mitigating RCEs is important, but it's not that important.
Making it a policy that can be enabled per-app (like Windows 10, according to a sibling comment) is fine though.
When .NET UWP applications are uploaded the store pre-compiles them on the server with .NET Native. The user only downloads and executes native code.
https://blogs.windows.com/buildingapps/2015/08/20/net-native...
One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.
The EMET mitigations which are no longer supported have either been depreciated because of better ones (control flow guard) or are not terribly effective (EAF/EAF+, use of debug registers).
[1] https://theryuu.github.io/ifeo-mitigationoptions.txt
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...