Microsoft 365 Sign-in Page Branding - 夜莺博客

Microsoft 365 Sign-in Page Branding

原文:Microsoft 365 Sign-in Page Branding — theDXT (Daniel Keer)

A custom-themed Microsoft 365 sign-in page can augment the user experience by making it easier to tell if it is a phishing sign-in page, as it will help users recognize whether the login page is legitimate or not. It also adds a nice custom tweak to your Microsoft 365 tenant.

Image 1

Microsoft 365 Sign-in Page before and after Company Branding

In this post, I will show you step-by-step how to customize your Microsoft 365 sign-in page.

Why company branding is a security control, not just decoration

Most technical controls against phishing rely on the user reading a domain name in the address bar, and most users do not. Company branding shifts that burden onto a visual check the user can perform without thinking: does the page carry our logo and our background image, or does it look like the generic Microsoft default? A page that appears the moment after a click, on the right logo, is far easier to trust than a URL string.

This matters more now that attackers routinely host convincing replicas. The value is not that branding makes phishing impossible — a determined attacker will copy a logo — but that it makes the legitimate page distinctive enough that users notice when something is off. Combined with Conditional Access and a passwordless or MFA requirement, it is part of a layered story you can actually explain to non-technical staff. For a deeper look at the policy half of that story, our guide on Entra ID Conditional Access and What If walks through evaluating a policy before you enforce it.

A second, quieter benefit: branding forces the tenant to have an identity. Once the logo and background are set, the tenant is recognisably "ours", which makes screenshot-based reporting from users much easier to triage.

The Process

  • Log in to the Microsoft Entra admin center
  • Click on User Experiences > Company branding

Image 2

  • Under Default sign-in experience, click on Customize

Image 3

  • Upload a Faviconthat is 32 x 32 pixels and less than 5 KB in size.
  • Upload a Background image that is 1920 x 1080 pixels and less than 300 KB in size.

The background image will be darkened by a black overlay with an opacity of 0.5.

Image 4

  • Click Next: Layout

  • Change the Layout as needed.

I like leaving it on the default settings and selecting the option to hide the footer.

Image 5

  • Click Next: Header

If you have selected the default option of hide the header, you can’t make any changes.

Image 6

  • Click Next: Footer

If you have selected the option to hide the footer, you can’t make any changes.

Image 7

  • Click Next: Sign-in form
  • Upload your Banner logo that is 245 x 36 pixels and less than 50 KB in size.

The banner logo is where the Microsoft logo is normally on the sign-in page.

Image 8

  • Upload your Square logo that is 240 x 240 pixels and less than 50 KB in size for the light theme.

The square logo doesn’t come up often. One of the places I’ve seen it is on the Windows Autopilot screen for Windows 10.

Image 9

On Windows 11, it displays the Banner logo.

Image 10

If your logo doesn’t look good on dark themes, you can upload an alternate square logo to be used on dark themes.

  • You can set a username hint. However, Microsoft recommends against this.
  • You can turn off the self-service password link if needed. I’ve opted to leave it as the default.

Image 11

  • Click Next: Review
  • Review the settings. If everything looks good, click on Create.

Image 12

It will take a bit for your new Login page to be active.

Image 13

Microsoft 365 Sign-in Page with Company Branding.

You can see what your login page screen looks like by replacing thedomain.com with your domain in the following URL https://myapps.microsoft.com/?whr=thedomain.com

It is common in some places for your branded sign-in page to only show up after the user enters their email address.

That’s all it takes to make a unique login screen for your Microsoft 365 tenant.

Image specifications at a glance

Screenshot the specifications before you brief a designer, because the aspect ratios are unusual and a badly proportioned logo is worse than none at all.

  • Favicon — 32 x 32 px, under 5 KB. Square, transparent PNG works best.
  • Background — 1920 x 1080 px, under 300 KB. Assume it will be darkened by a 0.5 opacity black overlay, so choose an image with contrast to spare.
  • Banner logo — 245 x 36 px, under 50 KB. This is a very wide, very short canvas; a square or stacked logo will be squashed.
  • Square logo (light) — 240 x 240 px, under 50 KB.
  • Square logo (dark) — 240 x 240 px, under 50 KB. Supply this if the light-theme logo disappears against dark backgrounds.

A practical tip on the background: because of the dark overlay, a photo with light tones in the middle will read better than a dark one, and any text baked into the image will be almost invisible. Keep the image as a mood, and let the logo carry the brand identity.

Language-specific and per-application branding

The default sign-in experience covers most tenants, but Entra also supports additional experiences for specific languages and for specific applications. A common pattern is a default experience in the organisation's primary language and an additional experience for a second language where the support footer links point at a localised helpdesk number.

Each additional experience is a separate object with its own images and text, and it inherits nothing from the default. Budget the time to upload the images again for each language you support rather than assuming the default will be reused. The exception is the sign-in page for a specific application, which you will see in the header when you first open the customisation blade — if you are editing the wrong object, your images simply will not appear on the page you are testing.

Testing what users will actually see

Do not judge the result from the preview pane in the admin centre alone. Preview panes render from cached assets and frequently look stale.

# Force the branded experience for a specific domain (replace the domain)
https://myapps.microsoft.com/?whr=contoso.com

# Test with a fresh, signed-out browser profile so no session
# state or cached asset masks the new branding. Incognito works.

# Check the tenant branding objects as returned by Graph
GET https://graph.microsoft.com/v1.0/organization/{tenant-id}/branding

Testing with whr= is the fastest way to confirm the branding without waiting for a user to hit the real page. Some tenants will only apply branding after the user submits their email address, so if you see the unbranded Microsoft page on first load, enter an address and continue before concluding the change failed. That behaviour is normal and is documented by Microsoft.

Also verify the experience in a private window where no cached credential is present, and check both a desktop browser and a mobile browser — the square logo and the layout behave differently at narrow widths. If your organisation fronts Microsoft 365 through a third-party access broker, confirm that the brokered path still shows the branded page; our note on Cloudflare Access as an identity provider with Entra ID covers where that flow diverges.

Common problems and how to clear them

  • Nothing changed after Create. Propagation is not instant. Wait fifteen to thirty minutes and retest in a private window before investigating further.
  • The banner logo looks pixelated. It was scaled up from a smaller source. Export at exactly 245 x 36 px at 2x and let the browser downscale rather than upscaling a small file.
  • Upload rejected for size. The KB limits are hard and apply before the file is stored. Run the export through an optimiser and re-check the byte size, not the dimensions.
  • Users still see the old page. Browser cache and stale session state. A private window and a different account settle this quickly.
  • Dark theme shows an invisible logo. Upload the alternate square logo rather than lightening the light-theme one.

One more item worth putting on the same change request: tell users what the new page will look like before it goes live. A branding change arrives as a surprise to staff who have spent years recognising the default page, and the security benefit evaporates if the first thing they do is report it as a possible phishing attempt. A short intranet post with the before-and-after image does more for the control than any amount of policy text.

Where the branding actually appears

New administrators are often surprised to find that one company-branding object does not reach every Microsoft surface. Knowing the boundaries saves a round of "it didn't work" reports.

  • Azure portal and Microsoft 365 web apps — fully branded, including background, logo and custom sign-in text.
  • Office desktop applications — the first sign-in shows the branded banner logo; subsequent token refreshes are silent and invisible to the user.
  • Windows Autopilot and device enrolment — the square logo on Windows 10, the banner logo on Windows 11. This is the surface most often forgotten when a rollout is planned.
  • Microsoft Authenticator and Intune Company Portal — partial branding; the square logo usually appears in the header of the provisioning flow.
  • Participant facing apps and third-party brokers — depends entirely on the integration. Test each one rather than assuming.

Write the list into your change documentation with a test result against each entry. A branding rollout is one of the rare changes where the "did it work" question has six different answers depending on where the user signed in.

Reproducing this with Microsoft Graph

If you manage multiple tenants, the portal is not the right tool. The branding endpoint on the organisation resource accepts the same settings, so the images become artefacts in source control and the tenant becomes reproducible.

PATCH https://graph.microsoft.com/v1.0/organization/{tenant-id}/branding
Content-Type: application/json

{
  "backgroundColor": "#1F3864",
  "signInPageText": "Authorised users only. Contact the service desk on x1234.",
  "usernameHintText": ""
}

Requires the Organization.ReadWrite.All permission, usually through an app registration with a certificate rather than an interactive login. Keep the credential for that app out of source control — store it in a managed secret — and treat the branding payload as code that gets reviewed. Our write-up on enabling organisation customisation in Microsoft 365 covers the surrounding tenant settings that a branding rollout usually touches, and saved browser passwords is a useful companion if you are tightening how users sign in.

To read more about adding company branding to your Microsoft 365 login screen. Here is the Microsoft documentation about it.