Checkride

A checkride is the practical exam where an examiner decides whether you are fit to fly. Not a quiz. An evidence-based determination, made by watching you actually do it, against a published standard, ending either in a certificate or in a specific named reason you did not get one. Nobody passes by asserting they are fine. That is the whole idea here, applied to a fleet of Windows endpoints instead of a pilot.

Every hardening baseline — CIS, STIG, the Microsoft security baselines — is a list of controls somebody else decided were a good idea. Applying them to a fleet you did not build is a guessing game: most will be harmless, a few will break something the business depends on, and you find out which is which after the change window closes. So most organizations either apply almost nothing, or apply a lot and spend the next month rolling back.

The question it answers is “what can you safely harden?” Not “are you compromised” — that is a different product with a different job. This one watches what an endpoint legitimately does, builds a behavioral model of it, and then gates each candidate control on a specific question: does anything this machine actually does depend on what this control restricts? Controls that nothing depends on are safe to apply. Controls that something depends on come back with the thing that would break, named.

Findings are emitted at setting level, tagged with CCI, so a governance platform can roll them up without either side needing to know how the other works. That handoff is deliberately one-way and there is no shared mapping library between them — two products that quietly grow into each other end up being neither.

Where it actually is: the behavioral model is complete as a library and its test suite is green, but nothing in it has executed outside a test. There is no running product, no installer and no pilot. It is on the bench, not in flight, and the remaining blockers are commercial rather than technical.