Custom CSS

The platform's theme-colour pickers cover 80% of branding needs. For the remaining 20% — "I want the sign-in form to have a card shadow", "the button corners should be sharp not rounded", "the form's typography should be Georgia" — Custom CSS is the escape hatch.

You paste a CSS string; the platform injects it as a <style> block on the sign-in page. Your rules override the platform defaults via CSS specificity.

Where to set it

Branding → Custom CSS. A code editor with syntax highlighting.

What you can target

The platform exposes these classes for branding-friendly targeting:

.ia-signin-card — the main sign-in form container.
.ia-signin-button-primary — the primary sign-in button.
.ia-signin-button-secondary — secondary buttons (e.g., "use a different method").
.ia-signin-input — text inputs (email, password, OTP).
.ia-signin-link — text links in the form.
.ia-signin-error — error messages.
.ia-signin-header — the section that contains the logo + greeting.

The full list is in the Custom CSS editor's help panel.

A simple example

Make the sign-in card less rounded + add a stronger shadow:

.ia-signin-card {
  border-radius: 4px;
  box-shadow: 0 10px 40px rgba(0, 0, 0, 0.15);
}

Override the button's corner radius:

.ia-signin-button-primary {
  border-radius: 0;
  text-transform: uppercase;
  letter-spacing: 0.1em;
}

Use a custom font (assumes you're hosting it; the platform won't fetch arbitrary external fonts in the sign-in page):

.ia-signin-card {
  font-family: 'Cymmetri Sans', Georgia, serif;
}

Validation

The editor validates the CSS for:

Syntax errors — bad braces, missing semicolons. Save is blocked until clean.
Disallowed rules — @import to external URLs is refused (we don't want the sign-in page to fetch arbitrary external resources). position: fixed over the whole viewport is refused (it could obscure the sign-in form).
Specificity overflow — rules with !important more than 10 times in a row are flagged. Usually a sign you're fighting the platform; consider whether you've found a bug instead.

Errors show inline. The editor doesn't try to be helpful beyond that; if you write valid-but-ugly CSS, it lets you save.

Preview

The Branding panel's live preview reflects your CSS as you type. Test layouts; iterate; save.

For "does my CSS look right in a real browser?", use the Open preview in new tab button. Renders the sign-in page in a real tab; click around; check responsive behaviour at different widths.

Save + audit

Save. CSS applies to the next sign-in load (no caching beyond the standard CDN cache).

branding.custom_css_updated lands in audit with the diff. Useful for "the sign-in page broke at 14:00 — what changed?"

Live with the trade-offs

Custom CSS is a sharp tool. Things it lets you do that you maybe shouldn't:

Override the platform's error styling, then have an "error" be invisible to users. Catch this in QA.
Reposition the sign-in form off-screen. Some malicious-extension-style customisations to make the form hard to find. The platform's validation catches blatant cases; subtle ones slip through.
Inject the user into a frame that intercepts inputs. Combined with custom HTML (not allowed on this surface), this could be a phishing surface. The platform doesn't allow custom HTML for this reason; CSS-only customisation can still be misleading. The audit log records who made the change.

For sensitive tenants (financial, healthcare), restrict who can edit Custom CSS via roles. The "Branding editor" custom-role pattern is a good fit — see Custom roles.

When you've gone too far

Two signs:

You're working hard to fix something that the platform's default handled. Consider whether the platform's default was fine and you've over-engineered.
Your CSS broke a sign-in feature. Roll back via audit ("Restore previous version" button next to any branding.custom_css_updated audit entry).

When in doubt, less is more. The platform's defaults are designed to be unobtrusive; significant customisation works against that.