Identity & sign-in

How users sign in — to the device and to the tenant — is decided by a handful of policies that interact far more than they appear to. Decolla configures them as one planned set in your own Intune tenant, with each change's reversibility declared before anything runs.

Why this matters

Sign-in is where a device build either earns trust or quietly erodes it. Leave Windows Hello for Business at tenant defaults and users meet a PIN enrolment wizard nobody planned for — or the organisation that wanted passwordless finds Hello was never actually on. Deploy Hello on cloud-native devices without a Kerberos story and sign-in works beautifully until someone opens an on-premises file share and hits an access error no event log explains.

First credentials are the other pressure point. A new starter's day one still usually begins with a password sent by email or read out over the phone — exactly the artefact passwordless was supposed to remove. And an otherwise well-managed device will happily accept a personal Microsoft account unless someone explicitly blocks it, which is how corporate files drift into personal OneDrive. None of this announces itself at deployment time; it surfaces weeks later as helpdesk tickets and quiet data leakage.

What a good build does

Identity settings interact, so Decolla treats them as one journey-ordered section of the catalogue rather than isolated toggles. The build configures Windows Hello for Business deliberately — including cloud Kerberos trust where on-premises resources still matter — uses a Temporary Access Pass so day one starts with a time-boxed credential instead of a password in an email, and blocks personal Microsoft accounts on corporate devices. The section's remaining sign-in behaviours are chosen deliberately in the same pass, not inherited from tenant defaults.

Before anything runs, the guided wizard produces a written, itemised plan: every item shows how it will be delivered and its reversibility class, with anything irreversible flagged, and nothing deploys until you approve that plan. Everything lands in your own Intune and Autopilot tenant as ordinary, inspectable configuration — no intermediary tenant, nothing opaque to audit afterwards. Rollback is scoped honestly: per item, Decolla removes the changes it made. It does not claim to unwind state that sits outside them — a Hello container a user has already enrolled, for instance — and the plan is explicit about which class each change falls into.

Where it bites people

Two failure modes recur in real tenants:

• Cloud Kerberos trust deployed half-way. The device-side policy is necessary but not sufficient: without the Microsoft Entra Kerberos server object created in on-premises Active Directory, Hello sign-in succeeds against Entra while access to file shares and other Kerberos-protected resources fails with errors that point nowhere useful. The device configuration and the directory prerequisite have to land together, and the gap between them is a notorious time sink to diagnose.
• Temporary Access Pass treated as a convenience rather than a credential. A TAP policy with long lifetimes or reusable passes is a standing bypass of strong authentication, not an onboarding tool. The pass should be short-lived and single-use — long enough for a user to enrol Hello or a security key on day one, and no longer.

Neither problem is exotic; both come from configuring items individually without seeing the sequence they belong to. Getting that sequence right is precisely what a plan-first, journey-ordered build is for.

What's in this section (6 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.