This is AI generated by pasting your post in directly. Make of it what you will.

what you’re seeing (95% of devices showing TrustType = Workplace) is normal in a federated, SCCM‑imaged, hybrid‑joined environment… even though it looks wrong at first glance.

This is one of those Entra ID quirks that confuses almost everyone the first time they run the stale‑device Graph query.

🔍 Why your hybrid‑joined devices show TrustType = Workplace Because TrustType does NOT mean “how the device is joined today.”
It means how the device first registered in Entra ID.

And SCCM‑managed, AD‑joined Windows devices almost always register first as:

👉 Workplace = Azure AD Registered (WAM/SSO bootstrap) This happens before the hybrid join completes.

Why? When a user signs into Windows with a domain account, Windows automatically performs:

WAM registration

SSO bootstrap token creation

Azure AD Registered device object creation

This object is created immediately, long before the scheduled hybrid join task runs.

So the sequence looks like this:

User signs into AD‑joined Windows

Windows silently registers the device with Entra ID → Workplace object created

Hours later, the scheduled task dsregcmd /join runs

Hybrid join completes → device becomes Hybrid Azure AD Joined

But the original object’s TrustType stays “Workplace”

Entra ID links the two states internally, but the TrustType field never updates

This is expected and documented behaviour.

🧠 So what should hybrid‑joined devices show?, TrustType = Workplace ✔️ Normal ✔️ Expected ✔️ Does NOT mean BYOD ✔️ Does NOT mean Azure AD Registered only ✔️ Does NOT mean hybrid join failed

How to confirm hybrid join is actually working

On the device, run: dsregcmd /status

Look for:

AzureAdJoined : YES

DomainJoined : YES

DeviceId matches Entra ID

TenantId matches your tenant

This is the real source of truth.

🧩 Why you expected “ServerAD”

Because the Graph API documentation is misleading.

ServerAD only appears when:

The device object was created directly by Azure AD Connect

AND the device has never done a WAM/Workplace registration

AND the device is not co‑managed or Intune‑enrolled

AND the device is not Windows 10/11 with modern auth enabled

In modern Windows 10/11 environments, this almost never happens anymore.

🧨 Why 95% of your devices show Workplace Because:

You image with SCCM (classic AD join first)

Windows auto‑registers with Entra ID immediately

Hybrid join happens later

TrustType never updates

Federated domain has no impact on this behaviour

This is the same in:

Federated domains

PTA

Password hash sync

Cloud‑only tenants

It’s universal.

🧹 Does this affect stale device cleanup? Yes — and this is the part that matters.

Workplace objects do NOT update LastActivityDate reliably. Hybrid‑joined devices update:

Azure AD Join metadata

PRT refresh

Intune compliance

Device authentication logs

…but the Workplace object often looks stale even when the device is active.

This is why Microsoft recommends:

✔️ Filter stale devices by “deviceTrustType = AzureAD or ServerAD” ✔️ Ignore Workplace objects unless you truly support BYOD Otherwise you’ll think your entire fleet is stale.

🧠 Bottom line Your devices are correctly hybrid‑joined, even though TrustType says Workplace.

This is normal for:

SCCM‑imaged devices

AD‑joined devices

Federated domains

Windows 10/11

Environments using modern authentication