How to password-protect a static site with Microsoft Entra ID

When people search for “password-protect a static site,” what they usually want for a company site isn’t a single shared password — it’s “only people at my company should see this.” A shared password gets leaked, never gets rotated, and tells you nothing about who actually viewed the page.

The better primitive is your identity provider. If your company runs Microsoft Entra ID (formerly Azure AD), you already have accounts, groups, and MFA. This guide gates a static site behind Entra so access is controlled by your existing directory: no shared secret, no custom code.

Why not a basic-auth password?

A quick comparison of the options people reach for:

Approach	Who can get in	MFA	Revocation	Audit
Shared password / basic auth	Anyone with the string	No	Rotate for everyone	None
Per-app user accounts	People you manually add	Maybe	Manual	Limited
Entra ID SSO	Your directory / a group	Yes	De-provision in Entra	Yes

For anything with real internal content, the Entra column is the one you want.

The fast path

You don’t need to register an app, run a proxy, or write OAuth code by hand.

1. Deploy your site

Upload your static build (drag-and-drop a zip, or bg-deploy ./dist). You can view it immediately via an email one-time code while you finish setup. Content is never served anonymously.

2. Map your domain first

Point one CNAME at BehindGate:

handbook.acme.com  CNAME  →  behindgate

Mapping the domain before wiring SSO matters: Entra binds its sign-in redirect to your final domain, so settling the domain first avoids reconfiguring and re-consenting the app later.

3. Connect Entra ID

Choose Microsoft Entra ID as the provider for the site. The lowest-friction setup uses your tenant ID (tid) so only accounts in your tenant can sign in. If your admin needs to grant consent, BehindGate gives you a one-click admin-consent link you can forward: no written runbook required.

4. Scope and harden

• Group access: assign the app to a specific Entra group so only, say, eng-all can read the site.
• MFA & Conditional Access: your existing Entra policies apply automatically, so you don’t reconfigure them per site.
• De-provisioning: when someone leaves and is disabled in Entra, their access here ends too. Nothing to remember to revoke.

What “fail-closed” means here

If access can’t be positively evaluated — a misconfiguration, an auth outage — the site denies the request rather than exposing content. A static site behind Entra should never “fail open” to the public internet, and this one doesn’t.

The result

handbook.acme.com is now readable only by the Entra accounts (or group) you chose, protected by your company’s MFA, with real de-provisioning and access logs, and not a single shared password to leak. Setup is about 15 minutes, and viewers are unlimited, so it costs the same whether 20 or 2,000 people can sign in.

The same steps work with Google Workspace if that’s your directory instead, or with your own custom OIDC provider.