Your Okta tenant, day one

Standing up an identity provider has an order that nobody tells you about, and it is not the order the onboarding wizard suggests. The wizard wants you to connect an application, because that is the demo. Connecting an application takes an afternoon and can be redone whenever you like.

The admin model and the naming convention cannot be redone whenever you like. Six months in, they are load-bearing, and changing them means touching everything at once.

Decide who can administer what, before anyone else has a login

Okta's own guidance on securing admin accounts starts with least privilege, and it is worth reading before you invite a single person. Two things in it get skipped constantly.

The first is the number of super admins. Okta's phrasing is to minimise super admins and use custom admin roles scoped to what a person actually does. Two super admins is a target you work back towards, not a starting point you drift up from. There is an admin role assignment report. Run it in week one and again every quarter, because the number only ever goes up on its own.

The second is scoping. Custom admin roles exist so that the person who resets passwords for the support desk cannot also rewrite your authentication policies. Most tenants I look at have four people who can do everything, because granting super admin took nine seconds and building a custom role took twenty minutes.

Phishing-resistant from the first login

Enable FastPass on the Admin Console authentication policy and require a registered device. Okta recommends both.

The reason to do this on day one is not that it is more secure on day one. It is that on day one it is a checkbox, and in eighteen months it is a project with a communications plan, a helpdesk surge and at least one executive who cannot get in during a board meeting. The technical work is identical. The organisational work is what changes.

Admin sessions are not user sessions

Three settings, and they are all under the same idea: an administrative session is more dangerous than a user session, so it should be shorter and harder to reuse.

• Re-authenticate after a short idle period. Not at the end of the day. After a coffee.
• Keep the session length well under the twelve hour ceiling Okta describes.
• Turn on admin session binding, so a session reused from a different network gets challenged rather than trusted.

The last one is the interesting one, because it is the control that actually addresses stolen session tokens, which is how identity providers get compromised in practice far more often than by password guessing.

Integrations are not people

Use API service integrations. That is what they are for, and it removes the password entirely.

If you genuinely have to use a user account, Okta's guidance is to put it in a group whose global session policy denies interactive sign-in, so the credential cannot be used to log in as a person even if somebody gets it. That single setting turns a shared password into something considerably less useful to an attacker.

The one you cannot retrofit cheaply

Naming. Decide it before the first group exists.

Every tenant I audit has three naming conventions and a layer of exceptions on top of them. Nobody chose that. It is what happens when the first twenty groups are created by four different people in a hurry, and nobody writes the convention down, and then the twenty-first group has to match one of the three that already exist and the person creating it picks whichever they saw last.

It does not have to be a good convention. It has to be one convention, written in a document that new admins read. role-department-scope is fine. app-environment-access is fine. What is not fine is all three of them in the same tenant.

If you inherited a tenant instead of building one

Run the admin role assignment report before you look at anything else. Not the app list.

The app list is what people show you, because it is visible and it looks like progress. The admin list is what determines how bad a compromise would be, and it is the one nobody has looked at since the tenant was created.