Browsers

Edge and Chrome are where the working day actually happens, and two browsers means two separate policy surfaces. Decolla configures both deliberately: identity, defaults, extension control, and the token plumbing that Conditional Access depends on.

Why this matters

The browser is where most of the working day happens, and on a fresh Windows build it is the least governed part of the estate. Left alone, users sign into personal profiles, sync work bookmarks and credentials to personal accounts, install extensions with read-everything permissions, and save passwords in the browser's own store — which quietly kills password manager adoption before it starts.

There is also a harder failure lurking here. Device-based Conditional Access depends on the browser handing the device's identity to Entra ID, and Chrome on Windows only does that reliably when the plumbing is deliberately in place — on an unmanaged estate, the behaviour varies with Chrome's version and local settings. If your policies require a compliant or joined device, sign-ins that succeed in Edge can fail in Chrome — and the resulting tickets look like account problems rather than what they are: missing token plumbing. Two browsers means two policy surfaces; treating them as one is how the gaps appear.

What a good build does

Decolla's Browsers section treats Edge and Chrome as separately managed surfaces, each with its own security, user-experience and extension policies — distinct configurations per browser, not one setting sprayed at both.

• Edge as the primary surface: signed into the work account with sync pointed at the work profile, with deliberate defaults and a considered security posture — so users land in a browser where sign-in behaves predictably.
• Chrome made a first-class citizen: the Windows Accounts extension deployed by policy, so device-based Conditional Access holds in Chrome regardless of version or local settings — with extension control applied on both sides.
• Credentials moved out of the browser: a password manager deployed and the browsers' built-in password saving disabled in the same move, so the ordering problem never arises.

As with everything Decolla deploys, each item appears on the written plan with its delivery method and reversibility class before anything runs — and Decolla can roll back its own changes per item afterwards.

Where it bites people

Chrome versus device-based Conditional Access. The classic pattern: a CA policy requiring compliant devices is rolled out, tested in Edge, and works. Then the users who prefer Chrome start hitting blocks and sign-in loops. Where the plumbing is missing — no Windows Accounts extension, and Chrome's own cloud sign-in support absent or switched off — Chrome cannot hand the device's Primary Refresh Token evidence to Entra ID, so the policy correctly refuses it. The fix is well known — deploy the extension by policy — but it is routinely discovered in production instead of at build time, after a long detour through phantom account issues.

Disabling browser password save in the wrong order. Turning off built-in password saving on an estate where people have years of credentials stored in the browser, without a password manager already in place, generates an immediate support wave and teaches users to distrust the change. The two controls have to land as a pair — manager in place first or alongside, browser save disabled with it — which is exactly how the catalogue pairs them.

What's in this section (14 items)

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