The problem with this approach is that it is tied to the thread that you are testing against. The thread's security context may not be the same as the one that was used to open the device in the first place. That means that it strays from the traditional semantics of all the access rights being computed up front and stored in the handle. So, if ThreadA opens the device, then dups the handle to another process, the kind of test described would violate the premise that the handle would have full fidelity access to the device. So, while the security check works, it's not fully consistent with how the Windows architecture defines the relationship between handles and devices.

A different way to handle this problem that preserves the handle semantics is to create a second, protected, interface. Anyone with WRITE_DAC access to this device could change the security descriptor on it. Thus, the user mode app, as easily as constructing a security descriptor and sending it down via an IOCTL to your driver (as in the previous method) could call SetKernelObjectSecurity() to directly change the device object's security.

In trying to solve a problem such as attaching appropriate security to a Device Object, it's important to look across the entire spectrum of possible solutions. The difficulty in doing this lies in the fact that few people understand possible solutions that exist in both kernel mode and user mode. In this case, it's clear that there's a ready made solution available to user-mode applications.