Stop blaming Microsoft if you are not informed.
As SYSADMIN you can install 3rd parties software. So it is not Microsoft granting, it is the owner of the server who trusted a third party (Crowdstrike) to have access the kernel. So blame the SYSADMIN, not Microsoft.
Microsoft doesn't certify that update because it is not their update.
So please, next time, before posting get informed.
Not a hill I'm ready to die on because I don't like those arguments myself. But I can understand what they are saying - the OS can gatekeep developers from doing crazy things with the kernel if they wanted.
For example, on iOS, you're not allowed to inject kernel drivers into the OS however hard you try. It limits the possibilities of the software and thus the usefulness, but also the possible impact of something like this happening.
For MacOS, kernel extensions (kexts) used to be a similar thing to Windows kernel drivers. But MacOS has phased them out in favor of system extensions, which are more sandboxed. This makes MacOS more useful than iOS but less risky than Windows.
In other words, on iOS and MacOS, the developer cannot cause the OS to crash or bootloop even if they wanted. But on Windows they can. And it is entirely in Microsoft's hands should they come out with a new OS that would not allow kernel drivers to be installed at all.
The problem with blaming Microsoft is that it assumed taking the MacOS approach has zero cost. In MacOS's push for system extensions (and similarly for OpenGL decom, 32bit decom, ARM transition), Apple's attitude has always been my way or the highway, because presumably software developers should rewrite their software from the ground up if they care about high value Apple users. Microsoft's attitude has been more of "if it worked 30 years ago it should keep working now". Taking Apple's approach would have business costs for Microsoft.