A password hidden from the person is still a password. Anything that can be typed can be stolen, guessed, shared or forgotten about.

When SWA is in use, three things are true at once. The application still has its own username and password for each person. Okta keeps a copy of that password so it can fill the login form. And the person can often still go to the application directly and type the password themselves, bypassing Okta altogether.

• The password still exists. It can be phished, guessed, reused or leaked from either end.
• Okta protects the tile, not the application. A stolen password works at the application’s own login page, with no second step.
• Leavers are not fully cut off. Disabling the Okta account stops the tile, but the application account and its password remain until someone removes them.
• Passwords are rarely rotated. The application owner has no reason to change a password that works.
• Shared logins hide who did what. Records show a team account, not a person.
• The browser plugin is a dependency. It must work on every browser, every version and every device.

None of this means SWA was a mistake. It was the best available bridge when applications could not do better. The question now is whether the bridge should remain the permanent road.

A clear definition helps decide which applications should move first.

Secure Web Authentication, usually called SWA, is a way for Okta to sign a person in to an application that does not understand modern sign-in standards. Okta stores the person’s username and password for that application, protected by encryption. When the person clicks the application tile, a browser plugin or extension opens the login page and fills in the stored values.

What it is

• A form-filling mechanism run by a browser plugin.
• A way to give one place to click for applications with old-style login.
• A stepping stone for applications that cannot yet use standards.

What it is not

• It is not federation. The application never receives a signed statement from Okta; it receives a typed password.
• It is not password-free. A password remains at the heart of it.
• It is not app-level multi-step sign-in. Okta may require a second step to open the tile, but the application itself will accept a password alone if typed directly.
• It is not provisioning. Creating and removing accounts in the application is a separate job.
• It is not a permanent design. It is a bridge.

Modernizing is a change in how the application trusts Okta. It is not a rewrite of the application.

To modernize an SWA application means to connect it to Okta using a standard federation protocol, usually SAML or OpenID Connect, so that the application accepts Okta’s signed statement of who the person is, and then to turn off the old password sign-in.

• Often the application already supports SAML or OIDC; it simply was never switched on.
• Sometimes support needs a higher licence tier from the vendor.
• Sometimes the application is too old and needs a gateway, a replacement or a compensating control.

Asking “Does it support SAML or OIDC?” is the first question for each of the 140 applications. The answer decides almost everything that follows.

A handful of words appear again and again. Learn them once and the rest of the guide reads easily.

Keep apart two ideas that are easy to confuse: sign-in proves who you are when you arrive; provisioning makes sure your account exists, has the right access and is removed when you leave. A modern setup does both.

Understanding the mechanism shows exactly where the weaknesses sit.

• The application never knows Okta was involved. It sees only a normal password login.
• Any change to the login page can break the form filling.
• The plugin must be installed and healthy on every device.
• The password is decrypted on the device at the moment of use.
• Anyone who learns the password can skip Okta entirely.

The last point matters most. The strength of the whole chain is the strength of a password that lives in two places and can be typed by anyone.

Auditors and attackers both look for the same things.

• Rank applications by how bad the loss would be, not by how annoying the migration is.
• Treat shared logins as the highest-risk SWA pattern.
• Treat internet-facing applications as higher risk than internal ones.

A fair account of the past makes better decisions about the future.

When Okta and similar services appeared, most business applications knew only usernames and passwords. SWA let companies offer a single place to click years before vendors added standards. It brought real benefits: fewer forgotten passwords, a central list of applications and a way to remove a leaver’s tile.

• Keep SWA for genuinely stuck applications, with extra controls.
• Never design a new integration as SWA if the application supports standards.
• Record every remaining SWA application with an owner and an end date.

Both standards do the same basic job: let one system prove to another who a person is, without handing over a password.

Imagine a conference. You show your identity at the registration desk, and the desk gives you a signed badge. At each room, the guard does not ask for your passport again; the guard checks that the badge is genuine and reads the name on it. The registration desk is Okta. The badge is the assertion or token. The room is the application.

SAML

• Older, very widely supported by business software.
• The statement is an XML document signed by Okta.
• Typical for browser sign-in to web applications.
• Needs certificates that expire and must be renewed.

OpenID Connect

• Newer, designed for web, mobile and programming interfaces.
• The statement is a token in a compact signed format.
• Typical for modern and mobile applications.
• Uses keys published at known addresses, which are rotated automatically in many setups.

For a legacy application, the choice is usually made for you: use what the vendor supports. If both are offered, many teams prefer OIDC for new work and SAML where the vendor’s SAML support is more mature.

Not every legacy application will become a SAML or OIDC application. Choose the right target for each.

• Ask the vendor first. Support often exists and was never switched on.
• Check licence tiers: some vendors charge more for SSO features.
• Choose replace or retire early for dead applications; do not spend effort modernizing them.
• Record the decision and reason per application.

Sign-in is half the job. The other half is making sure the right accounts exist, change and disappear.

SCIM is a standard way for Okta to tell an application, “Create an account for this person,” “Change their department,” and “Deactivate them.” Where an application supports it, accounts are created and removed automatically as the person joins, moves and leaves.

• Not every application supports SCIM; some offer just-in-time creation at first sign-in, or an older provisioning interface.
• Without any automation, plan a manual process with tickets and checks.
• Never think of SSO alone as leaver protection if the application keeps working local passwords.

The picture shows what changes and what disappears.

flowchart LR
    subgraph SWA["SWA: password fill"]
    A1["Person clicks tile"] --> A2["Plugin fills stored password"]
    A2 --> A3["App checks its own password"]
    end
    subgraph FED["Federation: SAML or OIDC"]
    B1["Person clicks tile"] --> B2["Okta checks person and policy"]
    B2 --> B3["Okta sends signed statement"]
    B3 --> B4["App trusts the statement"]
    end
    

After migration, a handful of parts do the work.

flowchart TD
    U["Employee or contractor"] --> OK["Okta sign-in and policies"]
    OK --> SSO["SAML or OIDC integration per app"]
    SSO --> APP["Modernized application"]
    OK --> PRV["Provisioning (SCIM or other)"]
    PRV --> APP
    GRP["Groups and rules in Okta"] --> SSO
    GRP --> PRV
    OK --> LOG["System Log and monitoring"]
    GW["Gateway or reverse proxy"] -.-> LEG["Legacy app that cannot use standards"]
    OK -.-> GW
    

Notice that groups feed both sign-in and provisioning. One decision about who should have the app flows to both halves.

Follow Anita from Brightwater’s billing team as she opens a migrated application.

sequenceDiagram
    participant A as Anita
    participant O as Okta
    participant S as Billing application
    A->>O: Clicks the billing tile
    O->>A: Checks session, asks for second step if policy says so
    A->>O: Proves identity
    O->>O: Applies app policy: group, device, network
    O->>S: Sends signed statement with email and role
    S->>S: Verifies signature and audience
    S->>S: Matches email to existing account
    S->>A: Opens session, no password typed
    

Notice step six. If the application cannot match the statement to her existing account, she gets a blank account, a new duplicate, or an error. Matching is where most migrations stumble.

List what Okta offers before planning the work.

You cannot modernize what you have not counted.

Start by listing every application that uses SWA in Okta. Then go further, because the list inside Okta is rarely the whole story.

• Export the application list from Okta and filter for SWA sign-in modes.
• Pull usage reports: who signs in, how often, last use.
• Check shared credential applications separately; they are the riskiest.
• Ask application owners and teams about tools used outside Okta.
• Review browser extension deployments and password manager exports for forgotten logins.
• Look at expense and procurement records for software nobody told IT about.

Once found, each application needs a few facts recorded.

• Keep it in one register, not in many spreadsheets.
• Assign a risk tier using data sensitivity, exposure and shared accounts.
• Record unknowns honestly and chase them.

This register is the backbone of the programme. Every later chapter refers back to it.

A short, standard list saves weeks of back-and-forth.

• Send the questions in writing and keep the answers.
• Ask for documentation links, not just yes or no.
• Ask the vendor for a test tenant if possible.
• Record vendor contacts and support routes.

You cannot move 140 applications at once. Group them into waves.

• Mix quick wins with risky targets so that progress is visible and risk falls early.
• Avoid waves that hit one team too hard at once.
• Align waves with contract renewals where possible.
• Respect business calendars: no migrations during month-end for finance apps.
• Review the plan monthly.

The most common reason a cutover fails is that the application cannot tell which existing account belongs to which person.

Before SSO, the application knows people by a username it has stored: maybe a short code, an old email address or a full name. After SSO, Okta sends a statement with an identifier such as an email address or employee number. The application must connect the two.

• Run a matching report: for each user in the application, which Okta user matches?
• Fix unmatched users before cutover.
• Choose a stable identifier that does not change when people change name.
• Test with real samples, including awkward cases.

A single login used by many people is the biggest hidden risk in an SWA estate.

Shared accounts exist because licences were limited, because setup was quick, or because someone created a login for a team and nobody changed it. They make it impossible to know who did what, and they survive staff changes.

• List every shared SWA login and who knows the password.
• Change those passwords at cutover and every time someone leaves while the account exists.
• Aim to eliminate shared accounts, not to hide them better.
• Where licences are the barrier, raise it with the business as a risk decision.

A modernized application that still accepts passwords is only half modernized.

After SSO is working, the application’s own login page may still accept usernames and passwords. An attacker with a phished or leaked password can use it, ignoring Okta completely. The job is not done until local password sign-in is disabled for ordinary users.

• Some vendors cannot disable local passwords for administrators; document and compensate.
• Some applications keep programming interfaces with their own keys; review them separately.
• Some have mobile clients that use passwords; check them.

The signed statement can carry more than a name. It can carry what the person is allowed to do.

• Send only the attributes the application needs.
• Define roles in Okta groups, and map each group to an application role.
• Check the application’s role names exactly; a mistyped role can lock people out or grant too little.
• Beware of attributes users can edit themselves; do not base roles on them.
• Review default roles: new users should not get powerful roles by accident.

Move from one-by-one assignment to rule-based groups.

• Create groups that match job functions or application roles.
• Use group rules based on profile data, where profile data is trustworthy.
• Assign groups to applications, not individuals.
• Name groups clearly: app, role, purpose.
• Give groups owners.
• Plan access reviews for sensitive groups.

This is also the best moment to clean up who has access. Do not copy bad assignments from the old tile into the new groups. Ask owners to confirm.

Each application passes through the same steps, whatever its wave.

flowchart TD
    A["Application selected for migration"] --> B["Vendor confirms SAML or OIDC support"]
    B --> C["Configure integration in test or preview"]
    C --> D["Match users and fix identifiers"]
    D --> E["Pilot with a small group"]
    E --> F{"Pilot successful?"}
    F -->|"No"| C
    F -->|"Yes"| G["Announce cutover date"]
    G --> H["Switch tile to federation, run parallel period"]
    H --> I["Enforce SSO, disable local passwords"]
    I --> J["Rotate or remove old credentials"]
    J --> K["Retire SWA tile, record evidence"]
    

Durations are illustrations. Simple applications move in days; complicated ones take months because of vendor work.

For a short time, the old and new sign-in may both work. Plan it carefully.

• Run the federated and SWA tiles side by side for a limited period.
• Make the new one the default and label the old one clearly.
• Set an end date and tell everyone.
• Watch usage numbers: how many still use the old path?
• Chase stragglers by name.
• Do not leave the old path open indefinitely.

Each application needs a test list before and after.

• Test with real people in each role, not only administrators.
• Test on the browsers and devices people really use.
• Keep test accounts for each role.
• Record results in the register.

Mistakes love the edges. Test what should fail.

• A user not in the group is refused.
• A leaver cannot sign in by any path.
• A local password no longer works, once enforcement is on.
• A stolen statement is rejected after expiry.
• A user with two accounts in the application is handled safely.
• A user whose email changed still matches.
• A very long session ends at the expected time.
• A user from a blocked place is refused by policy.

Not everyone reaches an application through a web browser.

Many business applications have mobile apps and desktop programs. These clients may use their own sign-in screens and, in older products, a stored password. SWA through a browser plugin does nothing for them. Modernizing is a chance to fix them too.

• Ask the vendor about client support for SSO before the cutover.
• Test real devices.
• Plan communication specifically for mobile users.
• Handle device-level rules, such as managed device requirements.

The last step of each migration is removing the old path.

• Remove the SWA tile and the old integration from users once the federated one is live.
• Delete the stored credentials held for that application.
• Remove the application from plugin deployment lists if the plugin is no longer needed.
• When no SWA applications remain, retire the plugin itself from devices.
• Update help pages and training.
• Record the retirement date in the register.

Retirement is the step teams skip. Without it, the old password still exists and the old path still works.

Some applications cannot speak SAML or OIDC at all. A gateway can stand in front of them.

A gateway, or reverse proxy, sits between the person and the application. The person signs in to Okta. The gateway checks the result and then passes the person to the application, sometimes by adding identity details to the request, and sometimes by filling the application’s own login in a controlled way.

• Place the application on a network where only the gateway can reach it.
• Protect the gateway as a high-value system.
• Plan for availability: if the gateway fails, so does access.
• Record the gateway as a temporary measure with an end date where possible.

Some applications are stuck, and honesty about them is better than pretending.

• Keep a list of stuck applications with owners and end dates.
• Apply extra controls: network limits, stronger tile policy, frequent access review, password rotation.
• Review the list quarterly; each vendor update may unlock support.
• Tell the business the risk and get an owner to accept it in writing.

Your timetable depends on someone else’s product.

• Send the standard questions early and chase politely.
• Ask for roadmaps where support is coming.
• Use renewals to negotiate SSO inclusion.
• Ask for test environments.
• Escalate through your account manager when support is slow.
• Keep a log of vendor commitments and dates.

Some vendors charge extra for SSO. Weigh it against the risk and the savings.

Illustrative arithmetic: suppose 40 of the 140 SWA applications need a licence uplift of 6,000 dollars a year each, or 240,000 dollars. If the programme removes 110 stored password sets, cuts password reset calls by 3,000 a year at 15 dollars each (45,000 dollars) and avoids one incident costing 400,000 dollars, the case is made on risk, not on direct savings. Use your own figures.

Federation lets Okta apply strong rules for every application, which SWA could not do at the app itself.

• Set the policy per application or per group of applications.
• Test the policy before enforcement.
• Include exception rules for emergency accounts, alarmed.
• Apply stronger rules to administrative access in each application.
• Review policies when applications change tier.

Signing in is easy to design. Signing out is where surprises hide.

• Decide how long an application session should last, in line with its tier.
• Learn what single logout really does for each application; many do not support it fully.
• Make sure that closing the Okta session eventually ends application sessions.
• Plan for shared computers and clear sign-out messages.
• Check idle timeouts in the application itself.

A SAML connection is only as alive as its certificate.

SAML uses a certificate to sign statements. Certificates expire, often after a year or more. When one expires, sign-in to that application fails for everyone. OIDC uses keys that are often rotated automatically, but the application must be able to follow the rotation.

• Keep a register of every SAML certificate with its expiry date.
• Set reminders at 90, 30 and 10 days.
• Learn the vendor’s renewal steps: some need a manual upload on their side.
• Plan renewal windows outside busy periods.
• Test the new certificate with a test user before switching.
• Assign an owner for each renewal.

Cutover is the beginning of watching, not the end of the project.

• Watch each application closely for two weeks after cutover.
• Create alerts for sudden drops in sign-ins.
• Compare Okta logs with the application’s own logs where possible.
• Review a weekly report during waves.

The first people to hear about a problem are the support staff. Give them what they need before cutover day.

• Hold a briefing a week before each wave.
• Give agents a one-page guide per application.
• Set up a fast escalation route to the migration team.
• Track calls by application and feed them back.
• Staff extra capacity in the first week of each wave.

People accept change when they know what, when and why.

• Write in plain language; avoid acronyms.
• Say what stays the same and what changes.
• Explain why: safer, no password to remember.
• Include screenshots.
• Warn people about look-alike phishing: the real message will only link to the company portal.

A short, practical session removes most fear.

• Offer a five-minute video per wave.
• Hold drop-in sessions for the first day of each wave.
• Train application owners in access requests, roles and what to do when someone cannot sign in.
• Train administrators in emergency procedures.
• Keep a frequently asked questions page up to date.

Every cutover needs a way back.

• Keep the SWA tile and credentials available, hidden or disabled, until the migration is stable.
• Define rollback triggers in advance: error rate above a number, key users blocked.
• Decide who can call a rollback and how fast.
• Know the steps: re-enable the old tile, turn off enforcement, tell users.
• Test rollback in preview.
• After rollback, explain and plan the corrected cutover.

Migrations fail in predictable ways. Plan for them.

flowchart TD
    A["Problem after cutover"] --> B{"What kind?"}
    B -->|"Nobody can sign in"| C["Check certificate, redirect address, clock; roll back if needed"]
    B -->|"Some users get blank or wrong accounts"| D["Check identifier matching; fix mapping or data"]
    B -->|"Roles wrong"| E["Check group to role mapping"]
    B -->|"Provisioning failing"| F["Check credentials and connector; fall back to manual"]
    B -->|"Old password still works"| G["Complete enforcement; close local login"]
    C --> H["Fix, retest, record lessons"]
    D --> H
    E --> H
    F --> H
    G --> H
    

After every incident, ask why it happened and why it was not noticed sooner. The second answer is often a missing alert.

A hundred and forty migrations create load on people, systems and vendors.

• Know the limits on integrations, groups and rules in your Okta edition.
• Plan rate limits for provisioning and bulk changes.
• Do not move many large applications on the same day.
• Check vendor limits on provisioning calls.
• Measure sign-in latency before and after.
• Plan team capacity: how many migrations can your people handle at once?

Migration touches personal data: names, emails, account lists, passwords.

• Treat exports of user lists as sensitive; store them securely and delete after use.
• Never put passwords in spreadsheets or tickets.
• Send only the attributes the application needs.
• Check where the vendor stores data and what contract terms apply.
• Delete stored SWA credentials after retirement.
• Keep logs only as long as needed.

No approach is perfect. Say plainly what you gain and what you pay.

State the downsides when you propose the programme. Leaders trust plans that name their own risks.

Patterns are habits worth repeating. Anti-patterns are traps others have already fallen into.

Some ideas sound sensible but lead teams astray.

A short list to read before every wave and every quarterly review.

• Every SWA app is recorded with owner, risk, vendor support, decision and date.
• Shared accounts are listed, prioritised and replaced.
• Vendors have answered the standard questions in writing.
• Targets are chosen per app: SAML, OIDC, gateway, replace, retire or compensate.
• Users are matched by a stable, organisation-controlled identifier.
• Roles are mapped from Okta groups, not user-editable fields.
• Provisioning is enabled where supported; manual processes are documented where not.
• Pilot first, then parallel run with an end date.
• Local password sign-in is disabled; emergency accounts are controlled and alarmed.
• Stored SWA credentials and shared passwords are deleted or rotated at retirement.
• Certificates are in a register with owners and reminders.
• Help desk, users and owners are briefed before each wave.
• Rollback is planned and tested.
• Monitoring is in place after cutover.
• Stuck apps have compensating controls, owners and end dates.

Zero trust says never rely on a password alone and always check the context. SWA applications are the opposite.

Every SWA application moved to federation is a small step toward a world where a stolen password is not enough. A leader asked why the company is doing this can answer simply: because passwords are the weakest link and we are removing them.

A migration of this size needs clear owners.

• Hold a weekly stand-up during waves and a monthly review after.
• Record decisions and exceptions in the register.
• Require sign-off from the application owner before enforcement.
• Give each application a named backup owner.

Show not only that apps were moved, but that the old paths are closed.

• Collect evidence as you go, not at the end.
• Keep it by application and date.
• Include before and after counts of SWA apps.
• Mask personal data in screenshots.

People move on. The programme must keep working without them.

• The application register: owner, tier, vendor, decision, dates.
• Per-application runbook: configuration, matching, roles, certificate details, vendor contacts.
• Certificate register: expiry dates and renewal steps.
• Emergency access procedure: who, how, how it is alarmed.
• Rollback plans and cutover checklists.
• Lessons log from each wave.

Test the documents. Give a runbook to a new colleague and watch. Where they stumble, the document needs repair.

Okta and application vendors change often. A migration done well can still drift.

• Read Okta release notes on a schedule.
• Watch vendor release notes for changes to SSO settings.
• Keep a list of assumptions, such as how an app matches users, and retest when a change touches one.
• Re-check enforcement after major vendor upgrades; some reset settings.
• Watch for renamed features and edition changes.
• Plan time each quarter for small fixes.

Write down which settings each application depends on. When a change is announced, you will know within minutes whether it matters.

Let us solve the problem from the start of this guide, step by step.

flowchart LR
    R["Register of 140 SWA apps"] --> V["Vendor answers"]
    V --> T["Target per app"]
    T --> W["Waves 0 to 4"]
    W --> C["Cutover: federate, match, enforce"]
    C --> X["Retire tile and credentials"]
    X --> M["Monitor and review"]
    M --> R
    T --> S["Stuck apps with compensating controls"]
    S --> M
    

A year later, 96 of the original 140 applications use SAML or OIDC with local passwords disabled, 22 are retired, 11 sit behind a gateway, and 11 remain on SWA with documented controls and end dates. The shared-login applications are all gone.

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

Scenario 1: Stock of Secrets

140 SWA apps with an average of 85 active users each hold roughly 11,900 stored credentials, plus 31 shared passwords known by perhaps 15 people each. Migrating 96 applications and retiring 22 removes about 10,000 stored credentials. The count of places where a password can be stolen falls by more than four-fifths.

Scenario 2: Leaver Exposure

Before, an SWA leaver lost the tile on the last day but kept a working application account for an average of 47 days. With provisioning and enforced SSO the exposure drops to under a day for federated apps. With 900 leavers a year across SWA apps, that is roughly 42,000 days of unneeded access reduced to a few hundred.

Scenario 3: Certificate Day

A SAML certificate for the payroll app expires on a Monday at 9:00 with 8,000 users. A register and 30-day reminder would have prompted renewal weeks earlier. The cost of an hour’s outage at 8,000 users at 40 dollars an hour is about 320,000 dollars. The register costs an afternoon to build.

You do not need to solve everything at once. Small steps beat grand promises.

The first 90 days

When someone says “I cannot get into the application since the change,” follow the same steps each time.

• State the exact problem: which app, which user, which time.
• Look at Okta’s log for that attempt and the app’s log if available.
• Compare with a working test user.
• Fix the case, then the cause, then check for others with the same pattern.

Before choosing a target for any app, answer the same short questions.

flowchart TD
    A["SWA application"] --> B{"Used in the last 12 months?"}
    B -->|"No"| C["Retire: confirm with owner, delete credentials"]
    B -->|"Yes"| D{"Does the vendor support SAML or OIDC?"}
    D -->|"Yes"| E["Federate, match, enforce, retire tile"]
    D -->|"No"| F{"Can a gateway or header integration protect it?"}
    F -->|"Yes"| G["Gateway with network lock-down"]
    F -->|"No"| H{"Is the app near end of life or low value?"}
    H -->|"Yes"| I["Replace or retire on a dated plan"]
    H -->|"No"| J["Keep SWA with compensating controls and owner"]
    

• If you cannot name the owner, find one before deciding.
• If the app has a shared login, move it up the queue whatever the target.
• If the decision is to keep SWA, write the end date.

Most migrations stumble on small details nobody wrote down.

Teams repeat the same early errors. Knowing them is a cheap kind of experience.

A strong design that people work around protects nothing. Colleagues must see the point and find the new way workable.

• Start with a story. The stolen laptop and the four-year-old shared password make the point.
• Show the benefit to users. No password to remember or reset.
• Involve application owners early. They own the roles and the acceptance.
• Respect busy periods. Keep finance away from month-end and HR from payroll weeks.
• Make the first wave a success. Pick willing teams and support them closely.
• Share progress. Show the falling count of SWA apps.
• Close old paths. People keep using what still works.

A concrete picture shows how the pieces behave together.

Nothing dramatic happens. That is the sign of a healthy programme: small items found early, old paths closed one by one and users who barely notice.

Not everyone who signs in to your applications is on the payroll. Contractors, auditors, partners and temporary staff often use the same applications, and they are easy to forget during a migration.

With SWA, a contractor often received a stored password and kept it long after the contract ended, because nobody told the application owner. With federation, access follows an Okta account, so the question becomes: does every contractor have one, and who ends it?

• Give each contractor a named account in Okta with a clear end date set when the account is created.
• Assign a sponsor, a real employee who answers for the account and confirms it each quarter.
• Use groups for contractor access, kept separate from employee groups so roles can be reviewed on their own.
• Check the vendor’s licence terms, since some applications count external users differently.
• Never let contractors share a login because a team of three does not need one password.

Include contractors in the discovery step. Ask each application owner who outside the company signs in, and compare the answer with the application’s own user list. Differences are the first findings of the programme.

Not every sign-in is a person at a keyboard. Scripts, scheduled jobs and other systems often sign in to applications using a stored username and password.

When local passwords are disabled at cutover, these quiet users are the first to break, usually at night when nobody is watching. The fix is to find them before enforcement, not after the first failed job.

• Search the application’s logs for accounts that sign in at odd hours or at perfectly regular intervals.
• Ask the owner which jobs, reports or integrations use a sign-in.
• Check whether the vendor offers tokens or keys for automated access, which are better than passwords.
• Give each automated account an owner, a purpose and a review date.
• Keep a short list of exempt accounts if the vendor allows local sign-in only for them, and protect those with long random secrets, network limits and alarms.

Record these accounts in the register. An automated account with no owner is a shared password with a robot’s face.

Leaders do not want a list of integrations. They want to know whether the company is safer than last quarter and what remains.

• Number of SWA applications, falling over time, with the target.
• Number of shared logins remaining, ideally heading to zero.
• Applications with local passwords disabled as a share of those federated.
• Applications with provisioning and removal tested.
• Certificates expiring in 30 days and whether each has an owner.
• Stuck applications with owners and end dates.
• Help desk calls related to the migration, per wave.

Show one small chart, one page of text and the decisions you need. Say plainly what is late. A report that shows only green loses trust the first time something fails.

Mergers bring new people and new applications overnight, and many arrive with their own SWA setups and shared passwords.

• Run the same discovery on the acquired estate before connecting anything.
• Do not import shared logins just to make a deadline.
• Decide which identity source is the master for the merged people, and match on a stable identifier.
• Expect clashes: two employees with the same email name, different formats of employee numbers.
• Prioritise internet-facing applications of the new company first.
• Agree an end date for the old directory so the merge does not leave two worlds permanently.

Treat the acquired applications as a new wave with its own register, owners and vendor questions. The method is the same; only the starting count differs.

Every business has weeks when change is unwelcome. Month-end for finance, enrolment for schools, harvest for farms, holiday season for retail.

• Collect the calendar from each application owner at the start.
• Avoid cutover in peak weeks, and avoid the day before holidays.
• Schedule cutover early in the week so help is available.
• Keep one spare window in each wave for problems.
• Do not stack certificate renewals and cutovers in the same week.

If a critical application has only one safe window a year, plan for that window and rehearse beforehand in a test setup. The rehearsal is cheap compared with missing the window.

The first wave teaches more than the plan did. Capture the lessons while they are fresh.

• Hold a short review within a week of each wave.
• Ask three questions: what surprised us, what took longer than expected, what would we change?
• Update the runbook template and the vendor questions with each answer.
• Share the lessons with the next wave’s owners, in writing.
• Keep a count of problems by type, such as identifiers, roles, certificates and communication, to see which cause most trouble.
• Thank the people who found the problems.

After three or four waves, the lessons log becomes the most valuable document in the programme, because it holds what no vendor guide will tell you about your own company.

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

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

SWA hides passwords. Federation removes them. Moving between the two is a programme, not a switch.