Supported way to prove absence of restricted device groups in a Windows access token?

NTDEV
1

I am looking for architectural guidance on a Windows security validation problem involving access tokens and TokenRestrictedDeviceGroups.

Environment:

  • Windows 11 25H2
  • OS Build 26200.9168
  • 64-bit Windows
  • Standard local non-administrator account
  • User-mode application
  • Process token opened with TOKEN_QUERY

The application performs a fail-closed validation of the Windows security context before allowing a security-sensitive qualification workflow to proceed.

During validation, the following GetTokenInformation queries are made against the same process token:

TokenGroups (class 2):

  • Initial size query returns ERROR_INSUFFICIENT_BUFFER (122)
  • ReturnLength > 0
  • Subsequent data query succeeds

TokenDeviceGroups (class 37):

  • Initial size query returns ERROR_INSUFFICIENT_BUFFER (122)
  • ReturnLength > 0
  • Subsequent data query succeeds

TokenRestrictedDeviceGroups (class 38):

  • Initial size query returns ERROR_INVALID_PARAMETER (87)
  • ReturnLength = 0
  • No second data query is possible

So, in simplified form:

TokenGroups (2) -> works
TokenDeviceGroups (37) -> works
TokenRestrictedDeviceGroups (38) -> ERROR_INVALID_PARAMETER (87)

The Microsoft documentation appears ambiguous:

  • The Win32 TOKEN_INFORMATION_CLASS documentation describes TokenRestrictedDeviceGroups as returning a TOKEN_GROUPS structure containing the restricted device groups associated with the token.
  • The NTIFS/kernel documentation marks the corresponding information class as reserved for system use.

For our threat model, we cannot interpret ERROR_INVALID_PARAMETER as meaning “the set of restricted device groups is empty.” An unsupported or failed query is not evidence of absence.

We investigated possible supported alternatives:

  • TOKEN_ACCESS_INFORMATION exposes RestrictedSidHash, but no restricted-device-group field.
  • IsTokenRestricted addresses the ordinary restricting SID list, not restricted device groups.
  • Public AuthZ context information exposes ordinary device groups and claims, but we could not identify a supported query for restricted device SIDs.
  • AppContainer state, capabilities, claims, ordinary device groups, and related token observations do not appear to contractually prove that the restricted-device-group set is empty.

Therefore our current implementation correctly fails closed.

The question is not primarily “how can we force class 38 to work?”

The architectural question is:

What is the supported Windows security design for a user-mode application that needs to establish, fail-closed, that an execution token does not contain restricted device groups?

In particular:

  1. Is there a supported user-mode API that exposes the same security property as TokenRestrictedDeviceGroups?
  2. If not, is there another supported security boundary or token-validation design that makes directly querying restricted device groups unnecessary?
  3. Is this property expected to be established at token creation time rather than inspected afterward?
  4. Would the recommended design be to create and retain a known token/security context, rather than attempting to prove all relevant token properties after the fact?
  5. Is TokenRestrictedDeviceGroups effectively unavailable to ordinary user-mode applications on current Windows despite the Win32 documentation?

We are specifically trying to avoid:

  • relying on undocumented NT APIs,
  • treating ERROR_INVALID_PARAMETER as an empty result,
  • weakening the security property merely to make validation pass,
  • or depending on implementation behavior that is not guaranteed by a public Windows contract.

Any guidance on the supported Windows architecture for this security requirement would be very helpful.

I can provide a minimal C/C++ or PowerShell reproduction of the class-38 behavior if useful.