Every person who uses your products passes through one small page. That page decides first impressions, safety and success rates.

Three Jobs in One Page

These jobs pull in different directions. Marketing wants freedom of design. Security wants strict control. Support wants plain words. A good design finds the place where all three are satisfied.

Okta offers a ladder of choices. Each step up gives more control and takes more responsibility.

Most companies should stop at the middle of this ladder. The farther down the table you go, the more security work moves from Okta to your own team.

A short dictionary makes everything later easier to read.

When the widget lives in your page, more of the journey happens on your domain. The order of steps changes, and so do the risks.

sequenceDiagram
    participant U as Person
    participant P as Your page with widget
    participant S as Okta service
    participant A as Your application back end
    U->>P: Opens your page
    P->>U: Shows the widget
    U->>P: Enters details inside the widget
    P->>S: Widget sends the attempt
    S->>S: Applies policies
    S-->>P: Result and one-time code
    P->>A: Passes the code
    A->>S: Exchanges code for tokens
    S-->>A: Tokens
    A-->>U: Session starts
    

• Your page sees more. A compromised script on your page can read the same things the widget reads.
• Cookie rules bite harder. The widget calls Okta from a different address, which browsers treat with suspicion.
• You own the upgrade path. New methods arrive when you upgrade the widget.
• You own the testing. Every browser, language and method must be covered by your own plan.

Do you send people to Okta’s page, or place Okta’s sign-in inside your own?

Okta has used more than one engine for sign-in logic. Which one you run changes what you can customize and how.

Okta’s older sign-in approach is commonly called the Classic Engine. The newer approach, built around flexible steps and policies, is called the Identity Engine. The two differ in how sign-in screens are built, which authentication methods are offered and how the widget talks to the service. The versions of the Sign-In Widget that match each engine are not always interchangeable.

• Know which engine your org uses. The admin console and documentation show this.
• Match the widget version to the engine. A mismatch can cause missing screens or odd behavior.
• Read the migration notes before upgrading. Custom templates and scripts may need rework.
• Test every custom screen after a move. What worked on one engine may not on the other.

Because this area changes quickly, treat it as a checklist item for your team: write down the engine, the widget version and the date you last confirmed them.

The simplest change is also the one with the best return: make the page look like you.

What Branding Usually Covers

• Logo. Shown at the top of the page. Provide a clear version that works on light and dark backgrounds.
• Colors. Primary and accent colors for buttons and links. Check contrast so text stays readable.
• Background. An image or color. Keep it quiet so the form stays the star.
• Favicon. The tiny icon in the browser tab. Small, but it reassures people.
• Page text. Welcome lines, help links and footer words in the voice of your company.
• Email and error pages. Okta lets you brand these too, so that every touchpoint matches.

Brand Discipline

Branding is easy to do once and hard to keep consistent. Keep the source files, the exact color values and the person who approved them in a shared place. If you have several brands, such as one per product or region, decide which applications use which and write it in a table.

An address that matches your company makes people trust the page and makes cookies and links behave better.

By default the hosted page lives at an Okta address. With a custom domain, it lives at an address such as one that begins with your own name. This helps in three ways. People see a familiar address. Emails and links look consistent. And some browser behaviors, such as how cookies are shared, work more smoothly when the address belongs to you.

Plans, certificate options and setup steps differ by Okta edition and over time, so confirm them in current documentation. A companion guide in this series covers custom domains in more detail.

When colors and logos are not enough, Okta may allow you to edit the page itself. This is powerful and needs discipline.

What Editing Allows

Depending on your plan and engine, you may be able to change the layout of the sign-in page, add your own words and links, change how some elements appear and adjust parts of the widget’s behavior with settings. Some editions also allow adding your own styling or small pieces of script to the hosted page. The exact limits are set by Okta and by your edition, so confirm them first.

Rules for Safe Editing

• Change as little as possible. Every edit is something you must retest after each Okta update.
• Use supported settings before custom edits. Settings survive upgrades far better than patches.
• Keep a copy of the original. A way back saves a bad afternoon.
• Review edits like code. A second person checks every change.
• Never add secrets or tracking you cannot explain. The page is public.
• Document each customization. Say what it does, why it exists and who owns it.

A picture of the parts shows who talks to whom and where each risk lives.

flowchart LR
    P["Person in a browser"] --> A["Your application"]
    A -->|"Redirect"| H["Okta hosted sign-in page"]
    A -.->|"Embedded option"| W["Sign-In Widget in your page"]
    H --> O["Okta authentication service"]
    W --> O
    O --> POL["Policies and sign-in methods"]
    O --> D["Directory and user store"]
    O --> L["System Log"]
    O -->|"Code returned to approved address"| A
    

• Browser. Runs the page and enforces many security rules.
• Your application. Starts sign-in and receives the result.
• Hosted page or widget. The visible screen.
• Authentication service. Applies policies, checks factors, and issues tokens.
• Brand and template settings. Decide how pages look.
• Logs. Record what happened for support and investigation.

Following one sign-in from first click to last redirect removes most of the mystery.

sequenceDiagram
    participant U as Person
    participant App as Application
    participant OK as Okta page
    participant S as Okta service
    U->>App: Opens the application
    App->>U: Redirect to Okta with a request
    U->>OK: Loads the sign-in page
    U->>OK: Enters username and proves identity
    OK->>S: Sends the attempt
    S->>S: Applies policies and checks methods
    S-->>OK: Result
    OK->>U: Redirect back with a one-time code
    U->>App: Delivers the code
    App->>S: Exchanges code for tokens
    S-->>App: Tokens for the session
    

1. The application starts sign-in and names where Okta may send the person back.
2. The person lands on the page and enters a name.
3. The service decides which methods to ask for, based on policies.
4. After success, the person is sent back with a short-lived code.
5. The application swaps that code for tokens in a safe back-channel call.

With an embedded widget, steps two and three happen inside your page rather than a separate one, but the same service decides the same things. That is why the widget does not remove the need for strong policies.

Different applications deserve different answers. A decision guide keeps choices consistent.

A hostile site can load your sign-in page inside an invisible frame and trick people into clicking things they cannot see. This attack is called clickjacking.

The defense is a browser instruction sent with the page that says which sites may place it inside a frame. For a hosted sign-in page, Okta sets protections, and you should confirm what they are and not weaken them. For an embedded widget, the page that holds it is yours, so you must send the right instructions yourself.

• Forbid framing by default. Allow only named, trusted sites when a real need exists.
• Test it. Try loading your page inside a frame on a test site and confirm the browser refuses.
• Check after every change. A new proxy or content delivery service can silently drop the instruction.
• Avoid exceptions for convenience. A partner who wants to frame your sign-in should use a proper redirect instead.

A Content Security Policy is the browser’s list of approved sources for scripts, images and connections. It is the strongest brake on injected code.

When a page tries to load a script from a source that is not on the list, the browser refuses. This turns many attacks into harmless errors. For sign-in pages the list should be short and boring: your own domain, Okta’s domain, and nothing else unless justified.

Introduce It Gently

Start in a report-only mode if the browser supports it. You collect reports of what would have been blocked, fix the surprises, then enforce. Switching on a strict policy without testing can break sign-in for everyone on a Monday morning.

Anything that can run script on the sign-in page can read what people type. Guard that door closely.

Where Unwanted Script Comes From

• Analytics and tag managers. Marketing adds them everywhere by habit, including the sign-in page.
• Chat and survey tools. Useful elsewhere, risky where passwords are typed.
• Compromised libraries. A supplier is attacked and a harmless script becomes harmful.
• Unsafe use of page data. Text from web addresses or messages written to the page without care can carry attacker script.

Habits That Help

• Keep the sign-in page free of tag managers and advertising scripts.
• Use fixed versions of libraries and check their integrity when the browser supports it.
• Keep an inventory of every script on the page and who approved it.
• Test with a scanner or review before every release.

Everything sent to a browser can be read by the person using it. Secrets must never travel there.

A web page, a widget settings file and a mobile app can all be opened and inspected by anyone. If a client secret, an API token or an admin key is placed in them, it is published to the world. Browser and mobile applications are therefore treated as public clients and use a method that needs no secret, normally the authorization code flow with a proof key known as PKCE.

• No client secrets in front-end code. Use a server for anything that needs one.
• No administrative tokens on the page. If the page can use it, so can an attacker.
• Use short-lived tokens. A stolen token that expires soon is less harmful.
• Scan repositories and builds for secrets. Leaks often come from a forgotten settings file.
• Rotate quickly after a leak. Have the steps written before you need them.

After sign-in, Okta sends people back to an address. If attackers can choose that address, they can steal the result.

Every application registers a list of approved return addresses. Okta only sends people to addresses on that list. The list must be exact and short. A wildcard that matches many addresses, or a test address left in production, is an open door.

Browsers keep tightening the rules about cookies. Sign-in designs that depended on old behavior can quietly break.

Single sign-on relies on a session cookie that Okta sets. Modern browsers restrict how cookies work across different sites, particularly when a page from one domain tries to use a cookie from another. An embedded widget on your site calling Okta’s domain is a classic case. A custom domain that shares your main domain family usually behaves better than a separate Okta address.

• Test in every major browser, including private modes and strict privacy settings.
• Expect change. Browser vendors update rules several times a year.
• Prefer designs that need less cross-site cookie sharing. The redirect model fits this well.
• Keep session lengths sensible. Long sessions help comfort but widen the window for theft.
• Explain sign-out. People should know whether they left only one application or all of them.

An error message has two readers: the honest person who is stuck and the attacker who is probing. Write for both.

The pattern is the same: say the same thing for different hidden causes, offer a next step, and put the detail in logs where only staff can read it. Which messages you can edit depends on your edition and engine, so confirm in current documentation.

Phones are where many customers meet your brand. The sign-in method must feel natural there and stay safe.

Typical Approach

For native apps, a common approach is to open the sign-in page in the system browser, or a secure in-app browser tab, and return to the app with a one-time code using a registered link. The app then exchanges that code for tokens, with a proof key so a stolen code is useless. The app never sees the password, and the page benefits from the phone’s own saved sessions and password managers.

Okta also offers mobile software kits and native sign-in approaches whose details change, so confirm current recommendations before choosing.

A public sign-in page is a magnet for automated attacks. The page and the service behind it need layers of defense.

Common Attacks

• Password guessing. Many tries against one account.
• Credential stuffing. Stolen passwords from other sites tried at scale.
• Account enumeration. Finding which emails have accounts.
• Fake sign-ups. Bots creating thousands of junk accounts.
• Phishing pages. Copies of your page on another address.

Layers of Defense

• Strong sign-in methods. Passkeys and app-based approvals resist stolen passwords.
• Rate limits and lockout rules. Slow down guessing without locking out the real owner for long.
• Challenges for suspicious traffic. Okta offers features such as risk checks and bot challenges, and the options depend on edition.
• Network and device signals. Unusual places or devices can raise the bar.
• Monitoring. Watch failures per minute, so an attack is seen in minutes, not days.

If some people cannot use the sign-in page, they cannot use anything behind it. Accessibility is a requirement, not decoration.

• Contrast. Text and buttons must stand out from their background. Test every brand color pair.
• Keyboard use. Every control must be reachable and usable without a mouse, in a sensible order.
• Screen readers. Fields need clear labels and errors must be announced, not just shown in red.
• Text size. The page must still work when text is enlarged or the screen is zoomed.
• Time. Give enough time for people to enter codes, and warn before sessions end.
• Plain language. Short sentences help everyone, including tired people on phones.
• No reliance on color alone. Use icons and words as well.

Okta’s widget and hosted page are built with accessibility in mind, and customizations can break that work without anyone noticing. Test with a keyboard and a screen reader each time you change the page. Standards and legal expectations vary by country, so ask your compliance team what applies to you.

People trust the sign-in page with their passwords. Clever tricks that push them toward choices they did not want break that trust.

• No pre-ticked consent boxes for marketing messages hidden near the sign-in button.
• No guilt wording on buttons that decline an optional step.
• Equal weight for choices. A person should be able to say no as easily as yes.
• Clear security prompts. Never imitate a warning to push a sale.
• No fake urgency such as countdowns on the sign-in screen.
• Plain explanations of why a step is requested, especially second steps and data requests.

Honest design is also safer. A page that trains people to click through odd screens prepares them to fall for a fake one. Teach customers that your real page is calm, consistent and asks only what it needs, so that anything different stands out.

A sign-in page that speaks the person’s language is one more reason they will finish signing in.

Okta supports showing sign-in pages in many languages, and you can adjust the wording in some of them. Good localization is more than translation. It also covers dates, address formats, right-to-left writing and cultural tone.

• Detect the language gently. Use browser settings, but let people switch.
• Translate with care. Use professional translators for security messages, since a wrong word can cause a wrong click.
• Test long languages. Some translations are much longer and may break the layout.
• Check right-to-left languages. Layout, icons and punctuation all need testing.
• Keep a glossary. Use the same translated word for the same idea everywhere.
• Update together. When the English text changes, schedule the other languages too.

Most customers will sign in on a phone, often in a hurry, sometimes on a weak connection.

• Design small first. One column, large buttons and fields that do not zoom the screen awkwardly.
• Help the phone help the person. Allow password managers and autofill. Never block pasting.
• Keep the page light. Compress images, avoid heavy backgrounds and load only what is needed.
• Plan for slow networks. Show progress, avoid timeouts that are too short, and handle a dropped connection politely.
• Respect the keyboard. Use the right keyboard type for codes and emails.
• Test on real devices. Older phones reveal problems new ones hide.

The Sign-In Widget is a ready-made piece of software that draws the sign-in screens and talks to Okta for you.

Instead of building every field, button and message from scratch, you place the widget in your page, give it a few settings, and it does the rest: showing the right screens for the policies you have set, handling errors and talking to Okta’s service. It is delivered as a software library that you can load from a content delivery network or bundle into your own application through a package manager.

For production use, most teams pin an exact version and deliver it from their own controlled source. Confirm the current delivery options and recommendations in the official documentation.

An embedded widget is software you operate. Software ages, and aged software is where attackers go looking.

• Pin the version. Know exactly which one runs in production.
• Subscribe to release notes. Someone on the team must read them.
• Plan a regular upgrade rhythm. For example, every quarter, plus emergency upgrades for security fixes.
• Test upgrades in a safe copy first. Check every sign-in path, not only the common one.
• Watch for breaking changes. Settings and customization points can change between major versions.
• Keep a way back. A previous version should be one change away.

The widget gives you many ways to adjust appearance and text. Using them wisely keeps upgrades painless.

Levels of Change, Safest First

1. Settings. Documented options such as logo, colors, language and which links appear.
2. Text overrides. Replace the words on screens to match your voice, one phrase at a time.
3. Styling. Add your own style rules for fonts, spacing and colors.
4. Behavior hooks. Supported points where your code reacts to events, such as showing a custom message after an error.
5. Structural changes. Moving or removing pieces of the screen. Risky, and often not supported.

Stay at the top of this list as long as you can. Each level down is more likely to break when the widget changes and more likely to damage accessibility or security.

Sign-in is only the happy path. The hard moments are forgotten passwords, locked accounts and first-time sign-up.

Recovery paths are as important as the front door. If resetting a password needs only a guessable fact, attackers will use the reset path instead of guessing the password. Review each recovery option with the same suspicion you apply to sign-in. Self-service features and their settings vary by edition, so confirm what you have.

Extra proof screens are where many people get stuck. Good design makes strong security feel simple.

• Explain why. One friendly sentence, such as “We ask for a second step to protect your account,” reduces complaints.
• Offer clear choices. Present the safest methods first and describe each plainly.
• Make enrollment easy. Step-by-step screens with pictures help people set up an authenticator or passkey.
• Provide a backup. Encourage people to enroll more than one method.
• Avoid weak fallbacks. Methods that can be tricked by a phone call or message should not be the easy way around.
• Prefer phishing-resistant methods. Passkeys and similar methods bind sign-in to the real address, so a fake page cannot reuse them.

Which methods are available, and how the screens look, depends on your Okta engine and edition. In an embedded widget, make sure the version you run supports the methods your policies require.

Many pages offer buttons such as “Continue with a work account” or “Continue with another provider.” These shape trust and routing.

• Show only what a person should choose. Too many buttons overwhelm people, and unneeded ones widen the attack surface.
• Use recognizable wording. Provider names and logos should follow that provider’s brand rules.
• Route by address when possible. Okta can send people from a company email domain to their own company sign-in, so they never see a long list.
• Think about account linking. Decide how a social sign-in is matched to an existing account, and prevent takeover by a matching email that was never verified.
• Plan for provider outages. If an outside provider is down, people need another way in.

Larger companies run more than one brand. Each should feel right while the system behind stays simple.

Whichever you choose, write a table that says which application shows which brand, who approves changes and where the source files are kept. Without that table, brands drift and the sign-in estate becomes a puzzle.

The sign-in journey includes messages and pages outside the sign-in screen. A mismatch there is jarring and sometimes dangerous.

• Email templates. Welcome, reset and verification emails should carry your name, voice and a clear way to report suspicious messages.
• Text messages. Keep them short, say who is asking, and never ask people to share a code with a person who calls them.
• Error pages. Okta lets you brand error pages. Make them calm and helpful, with a way to reach support.
• Sign-out pages. Say what ended and where to go next.
• Sender trust. Set up sender checks for your email domain so that messages are not marked as spam or forged.

Phishers copy these messages. Using the same wording and the same addresses every time helps people notice a fake. Changing them often teaches people to ignore differences.

Changes to a sign-in page should never be tried first on real customers.

• Use separate Okta orgs for test and production where possible, so a mistake cannot reach real people.
• Keep the settings of all environments in a record, and compare them before release.
• Use separate applications and return addresses for each environment.
• Remember that a test page can still be found by attackers. Give it the same protections.

A sign-in page has many paths. A written test plan keeps rare ones from being forgotten.

Automate what you can, such as checks that run after each change. Keep a short manual checklist for what machines do poorly: reading a message as a confused person would. Run the full set before every release and after every Okta change that affects the page.

Neither browsers nor Okta stand still. A page that was perfect last year may be quietly breaking this year.

Give one person the duty of reading these sources each month and writing three lines for the team: what changed, whether it affects us, and what we will do. Small, regular attention beats a yearly scramble.

Even tested changes can surprise real traffic. Release in small steps with a way back.

Choose quiet times. Avoid releases just before holidays, sales or other busy periods. Tell support in advance, so a spike in questions is expected.

Not every option is available on every plan, and names change. A short confirmation list prevents expensive surprises.

• Whether your plan allows custom domains and how many brands.
• Whether the hosted page allows template editing, custom styling or scripts.
• Which engine you run, and which widget versions match it.
• Which sign-in methods your plan supports and how they appear on screen.
• Which error, email and sign-out pages can be customized.
• Which risk and bot protections are included.
• Limits on requests, including those that apply to sign-in traffic.
• What support covers for customized or embedded pages.

Write the answers, with the date and the document you read, in a short page that your team can find. When behavior surprises you later, that page tells you whether you misread the rules or the rules changed.

Zero trust means no request is trusted only because of where it came from. The sign-in page is where that idea first meets a real person.

What the Page Contributes

The page does not make the trust decision alone, but it gathers the evidence that the service uses: who the person claims to be, which proof they offer, and clues about the browser and device. A page that is easy to spoof, easy to script or easy to bypass weakens the evidence from the first step.

• Show the real address. A familiar custom domain helps people notice fakes.
• Prefer phishing-resistant methods. Passkeys check the address of the page, so a copy elsewhere gets nothing.
• Ask for more when risk rises. New device, new place or sensitive application can trigger stronger proof through policy.
• Do not trust the page alone. Applications still verify tokens and check permissions on every request.
• Log the evidence. What was asked and what was answered should be traceable later.

Which risk signals and policy options exist depends on your Okta edition, so confirm them in current documentation.

Design agencies, consultants and outside developers often touch the sign-in page. They bring skill, and they also bring access.

• Give a brief, not the keys. Provide the brand guide, the rules about scripts and the test plan. Let them work in staging with fake users.
• Limit access. Give outside people the smallest Okta role that lets them do the job, and remove it on the last day.
• Review everything they deliver. Check for added scripts, tracking, copied code and unusual network calls.
• Own the source. Contracts should say the code and design files belong to you and are handed over in full.
• Ask for documentation. What was changed, why, and how to undo it.
• Plan the handover. Someone on your team must be able to maintain the work when the contract ends.

A short checklist given at the start of every engagement saves arguments at the end, and keeps well-meaning helpers from adding a chat tool or a tracking tag to the one page where it matters most.

The sign-in page touches marketing, security, support, legal and engineering. When everyone owns it, nobody does.

Name one accountable owner and one deputy. Keep a change record with who asked, who approved and when. Meet quarterly to review the page, the incidents and the requests waiting.

Support staff hear about sign-in trouble before anyone else. Equipping them well turns complaints into clues.

• Give them a view of the page. They should see what customers see in each language and brand.
• Teach the common causes. Old browsers, saved wrong passwords, clock problems on phones, ad blockers and privacy settings.
• Script the identity check. Support must verify callers before changing anything, and the steps must be as strict as the rest of the system.
• Give a way to escalate. One simple form with time, address, browser and screen text.
• Collect patterns. A weekly note of the top five complaints guides what to fix next.
• Protect against social engineering. Attackers call support pretending to be locked-out customers. Staff must be allowed to say no.

You cannot fix what you cannot see. A handful of measures tell you whether the front door is healthy.

Okta’s System Log records sign-in events, and you can stream it to your own monitoring platform. For embedded pages, add measures from the browser side too, taking care not to collect passwords or more personal data than needed. Event names and streaming options change, so confirm them in current documentation.

When sign-in fails, every other system becomes unreachable. Alerts must be quick, and the response must be rehearsed.

Alerts Worth Having

• Sign-in success rate drops sharply for ten minutes.
• Failed sign-ins spike from one network or country.
• Certificate within thirty days of expiry.
• Browser errors from the page rise after a release.
• Domain or address records change unexpectedly.

When Something Breaks

Thinking about failure before it happens turns panic into procedure.

flowchart TD
    S["Sign-in is failing"] --> Q1{"Is Okta reporting an incident?"}
    Q1 -->|"Yes"| W["Follow status updates and use fallback plan"]
    Q1 -->|"No"| Q2{"Did we release a change recently?"}
    Q2 -->|"Yes"| R["Roll back the change"]
    Q2 -->|"No"| Q3{"Is the certificate or address record wrong?"}
    Q3 -->|"Yes"| F["Fix certificate or records"]
    Q3 -->|"No"| Q4{"Is an outside script or provider failing?"}
    Q4 -->|"Yes"| B["Remove or bypass that dependency"]
    Q4 -->|"No"| I["Escalate to deeper investigation with logs"]
    

A slow sign-in page costs customers silently. People rarely complain; they simply leave.

• Keep the page small. Fewer and lighter files load faster, especially on mobile networks.
• Use caching wisely. Static files such as images and style sheets can be cached; the sign-in logic cannot.
• Serve from nearby. A content delivery service reduces distance for far-away users.
• Avoid blocking requests. Do not make the page wait for analytics or fonts from other sites.
• Plan for spikes. Product launches, sales and morning log-on peaks multiply traffic. Ask Okta about limits that apply to your org and test your peak.
• Watch sign-in time end to end. The slowest step is usually not the page, but an extra method or a slow policy.

The sign-in page sees names, emails and sometimes locations. What it collects, shows and stores needs thought.

• Collect the minimum. Every extra question lowers completion and raises responsibility.
• Be clear about purpose. Say why you ask, in plain words, next to the question.
• Show links to terms and privacy notices where people can reach them before they commit.
• Handle consent honestly. Do not pre-tick boxes that need a real choice.
• Be careful with analytics. Page analytics can capture typed data or addresses with personal details in them.
• Limit log contents and retention. Keep what is needed for security and audit, and no more.
• Remember children. If young people may use your service, special rules often apply.

Auditors do not only ask whether the page is secure. They ask how you know, and how you would prove it.

Collect evidence as a habit, not in a panic. Save one screenshot or export per control per quarter, with the date and the name of the person who checked it.

Every customization has a price in time, testing and risk. Seeing the price helps you pick wisely.

Include people’s time and attention in the price. A page that needs two engineers every time a browser changes is a much more expensive page than its first estimate suggested. Ask what you will stop doing in order to keep it alive.

Customization is a trade: a better fit for more work and more risk.

Teams keep rediscovering the same good and bad habits. Naming them helps you follow the first and avoid the second.

Some beliefs sound sensible and lead to poor decisions.

A single page to run through before launch and every quarter after.

• We chose hosted or embedded on purpose, and wrote the reason.
• The page runs on our own domain with a tracked certificate.
• Branding is approved, consistent and stored in a known place.
• We know our Okta engine and widget version, and we pin them.
• Framing is forbidden except for named, documented cases.
• A Content Security Policy limits scripts and connections to trusted sources.
• No tracking, advertising or unknown scripts run on the page.
• No secrets or admin tokens are in browser code.
• Return addresses are exact, secure and separated by environment.
• Error messages are calm, consistent and reveal nothing secret.
• Rate limits and bot protections are on, and failures are monitored.
• The page passes keyboard, screen reader and contrast checks.
• Every supported language is tested, including long and right-to-left.
• Recovery routes are as strong as sign-in.
• Changes are reviewed, staged, rolled out slowly and reversible.
• Owners, deputies and the review calendar are written down.
• Evidence for audit is saved every quarter.

Let us walk through Kestrel Outdoor Gear’s problem from the start of this guide and fix it in order.

flowchart LR
    W["Kestrel website"] -->|"Redirect"| H["Branded hosted page on Kestrel domain"]
    M["Mobile app"] -->|"System browser"| H
    P["Partner portal"] -->|"Redirect"| H
    C["Checkout page"] -->|"Embedded widget by exception"| E["Pinned widget version"]
    H --> OK["Okta service and policies"]
    E --> OK
    OK --> LOG["Logs and alerts"]
    

Numbers make the stakes visible. All figures here are illustrative, built to show the thinking and not to predict your results.

Scenario 1: The Slow Page

Kestrel’s old sign-in page took five seconds to become usable on mid-range phones because of a large background image and two marketing scripts. Suppose 400,000 sign-in attempts happen each month and the slow page causes three in a hundred people to give up. That is 12,000 lost sign-ins a month. After the redesign, the page loads in two seconds and the abandon rate falls to one in a hundred, or 4,000. The difference of 8,000 sign-ins a month is a direct sales and support gain.

Scenario 2: The Certificate

The sign-in domain certificate expired on a Sunday night. Browsers showed a warning to everyone for six hours until an engineer was found. If an average hour carries 600 sign-ins, that is 3,600 failed attempts, a flood of calls and a lot of lost trust. An alert at thirty days and seven days, with a named renewer, would have cost almost nothing.

Scenario 3: The Friendly Error

A test showed that the old reset page replied differently for known and unknown emails. An attacker script checked 50,000 addresses in one afternoon and found 9,000 real customers to target with phishing. A single consistent message removed that advantage at once.

Leaders fund what they can see. A few simple measures show whether the work is paying off.

Report once a quarter on one page, with a short story such as the sale weekend when sign-ins stayed smooth. Numbers persuade the head, and stories persuade the heart.

You do not need to do everything at once. A path of small, safe steps works better than a big promise.

The First 90 Days

When a customer says “I cannot sign in,” a steady routine finds the cause faster than guessing.

The Routine

• Ask for the exact time, address, browser and what the person saw.
• Find the matching events in the logs.
• Reproduce it in staging with the same browser and language.
• Change one thing at a time.
• Write down the cause and add a check so it is caught next time.

When someone asks for a custom sign-in change, ask the same short questions in the same order.

flowchart TD
    A["Request for a custom change"] --> B{"Can branding settings do it?"}
    B -->|"Yes"| C["Use branding settings"]
    B -->|"No"| D{"Can a supported text or template setting do it?"}
    D -->|"Yes"| E["Use the supported setting and document it"]
    D -->|"No"| F{"Is there a strong business reason for a custom edit?"}
    F -->|"No"| G["Decline and explain"]
    F -->|"Yes"| H{"Is hosted page editing enough?"}
    H -->|"Yes"| I["Edit the hosted page with review and tests"]
    H -->|"No"| J["Embedded widget with owner, pinned version and review date"]
    

• If you cannot explain the benefit in one sentence, it is not ready.
• If the change cannot be tested, do not ship it.
• If it adds a script from outside, the answer is almost always no.
• If it changes error text, ask security to review it.

Most sign-in projects stumble on small details that no one wrote down.

Success looks quiet: small routines, few surprises and no heroic rescues.

Notice what is missing: no weekend outage, no mystery pages and nobody asking who built this three years ago. That calm is the real product of careful work.

Teams repeat the same early mistakes. Knowing them in advance is a cheap kind of experience.

A secure, well-built page that others work around protects nothing. People follow the path that is easiest and best explained.

• Explain benefits in their terms. Marketing hears “consistent brand and higher completion.” Security hears “fewer attack routes.” Support hears “fewer confused calls.”
• Give a design guide. One page with approved colors, wording and rules about scripts and exceptions.
• Provide a fast request route. If the official way takes months, people will build their own page.
• Pilot with a friendly team. Collect feedback and a success story.
• Close old paths. Retire old copied pages and redirect them.
• Report progress. Share sign-in success rates and support call reductions with leaders.

Old sign-in pages linger on forgotten servers, in old emails and on partner sites. Each one is a door that nobody watches.

• Find them. Search your code, your domains, your email templates and your partners’ documents.
• Check their traffic. Pages still receiving sign-ins need a migration plan, not a switch-off.
• Redirect gently. Send old addresses to the new page for a time, with a notice.
• Remove registered return addresses that no longer belong to a live page.
• Remove old credentials and keys. Anything that ever sat on an old page may be copied.
• Watch for takeover. An unused address that points nowhere can sometimes be claimed by someone else.
• Record the retirement. Date, reason and approver, for audit.

Engineers move on. A sign-in page that only one person understands is a risk with a name and a leaving date.

Once a year, ask someone new to follow the runbook in staging. Wherever they stumble, the document needs work.

Quick plain-language meanings for the words used in this guide.

Short answers to questions that come up in almost every project.

The sign-in page is both the front door and the first line of defense. Good customization makes it welcoming without making it weaker.