[Solved] Why cannot ObReferenceObjectByHandle?

My customer has a service protected by ELAM. It opens a handle to USB device (obtained from SetupDiGetDeviceInterfaceDetail) and passes to a kernel driver, which calls ObReferenceObjectByHandle on this handle. But it fails with STATUS_ACCESS_DENIED.
When I dump the handle in windbg it prints this:

: kd>  !handle @@(hDevice) 

PROCESS ffff80811a7ae2c0
    SessionId: 0  Cid: 0a6c    Peb: 16d1fb1000  ParentCid: 0308
    DirBase: 1a77fb002  ObjectTable: ffffcb063e9fe600  HandleCount: 464.
    Image: MyService.exe

Handle table at ffffcb063e9fe600 with 464 entries in use

076c: Object: ffff80811f755480  GrantedAccess: 00100080 (Protected) (Audit) Entry: ffffcb063ef97db0
Object: ffff80811f755480  Type: (ffff8081120a7640) File
    ObjectHeader: ffff80811f755450 (new version)
        HandleCount: 1  PointerCount: 1

Does the '(Protected)' mean that the handle comes from a protected process and even a driver cannot touch it? What means (Audit) ?

Is there a way for a driver to overcome this protection and get the device reference?

Update: after removing the ELAM protection from the service (there's no longer "Protected" in !handle output) I still get STATUS_ACCESS_DENIED. The call is:

PFILE_OBJECT pFile;
NTSTATUS status = ObReferenceObjectByHandleWithTag(hDevice, SYNCHRONIZE | GENERIC_READ, *IoFileObjectType, UserMode, 'AAAA', &pFile, NULL);

Before the call the handle had GrantedAccess: 00100080 (SYNCHRONIZE and READ_ATTRIBUTES) and now I request GENERIC_READ. Why it can fail?

Solved. It appears that device objects of USB devices do not support GENERIC_READ (is it only for file objects?) Combination of SYNCHRONIZE
and FILE_READ_ATTRIBUTES is OK. This succeeds:

NTSTATUS status = ObReferenceObjectByHandleWithTag(hDevice, SYNCHRONIZE|FILE_READ_ATTRIBUTES , *IoFileObjectType, UserMode, 'AAAA', &pFile, NULL);