For more from Microsoft on when/how driver certificate revocation works, see the comment section on the blog on the Atsiv revocation. Sounds like the current architecture only allows for boot-time checks, and they're just speculating that checks with VeriSign could be done more frequently:

The VeriSign revocation list may impact a variety of operations. For example, verification checks that request online CRL validation will fail, which is more common for user mode operations. This can also extend to functions such as online time stamping combined with signing of new code. The frequency of these checks is application specific, and also depends on factors such as the requested CRL verification policy (online network, vs. offline without fresh cached CRLs, etc).

Right, but we're talking about kernel mode device drivers here. So I'm guessing that those only occurr at boot time too. Microsoft's analogies to patches, which also often require reboots, work to a point. You might get a notification from automatic updates that you need to reboot because of a patch, but you might never know that a cert is revoked, and go a month or more before rebooting. Here's a compromise proposal: A program (maybe I could write this myself. Hmmm...) that just does a a cert check on all loaded drivers and code and reports back to the user, perhaps with some action choices based on what it finds. The program can be set to run periodically.