Integrations · Okta & Duo

The front door, and the second look.

Households and family offices that ask hard questions already have answers they trust: Okta for who gets in, Duo for making sure it is really them. Tidemere joins that system instead of asking anyone to manage one more password.

The posture

Identity belongs to the organization. We defer to it.

Serious households and family offices already run identity the way serious companies do: one directory of who belongs, one place to add a person, one place to remove them. The worst thing new software can do is sit outside that system with its own logins and its own forgotten-password flow.

Tidemere plugs into the directory instead. Okta decides who can sign in. Duo confirms it is really them at the moments that matter. And when someone leaves the organization, their access to Tidemere ends where everything else ends: in the one place the organization already controls.

Okta · the front door

Their identity, your sign-in.

Staff sign in to Tidemere with the account their organization already manages. There is no separate Tidemere password to create, remember, or reset, and no orphaned account waiting to be forgotten about.

The directory stays in charge. Add someone in Okta and they can sign in; choose which groups have access and Tidemere honors it; remove someone once and every connected application follows, the same hour.

No separate password, ever Access follows groups the organization already defines Offboard once, in Okta, and Tidemere access ends with it
The directory, in charge
Added in Okta
Signs in to Tidemere with the identity they already have.
Moved to a new role
Group change in Okta; Tidemere's view reshapes to match.
Removed in Okta
Tidemere access ends the same hour, with no call to anyone.
Where the second look happens
Signing in
A tap on their phone confirms it is really them.
Opening emergency information
A family's contacts and medical notes warrant a second look.
Changing who sees a household
Access changes are sensitive by definition.
Duo · the second look

A quiet confirmation, where it matters.

On sign-in, or before a sensitive action, Tidemere asks Duo to confirm the person is who they claim to be, usually a single tap on their phone. The organization's own policy decides which actions warrant the prompt; Tidemere enforces it.

Tidemere never sees how the person verified. Duo reports only that the check passed. The security detail stays with the security system.

One pattern, every connection

Scoped. Revocable. Passwordless.

Okta and Duo connect to Tidemere the same way Google, Microsoft, and Notion do, because it is the only pattern worth trusting.

Scoped

Your admin chooses exactly what each connection may see and do. Typically a name, an email address, and group membership. Nothing more is visible to us.

Revocable

Every credential can be turned off at any moment from your own console, with no call to us required. If a connection ends, there is nothing left behind to retrieve.

Passwordless

Tidemere never sees or stores a password, for anything, ever. Keys are issued by your systems, to your rules, and they work only for what you granted.

How we connect

Two consoles, one afternoon.

1

Your IT admin adds Tidemere in Okta

From their own admin console, they register Tidemere as an application and choose which groups may sign in. Nobody at Tidemere touches your directory.

2

They register Tidemere in Duo

As a protected application, with your own policy for which actions require the prompt and how often.

3

Each system hands us a scoped key

Credentials that work only for what was granted, revocable from your own consoles at any moment. From then on, sign-in and verification simply work, and your directory stays the single source of truth.

What we need from you

An hour with whoever administers Okta, and Duo if it is a different person The list of groups who should be able to sign in, by role Your policy call on which Tidemere actions warrant a Duo prompt

No Okta or Duo yet? Tidemere also runs standard sign-in with its own verification for organizations that have not adopted an identity platform, and moves to this pattern when you do.

Next step

Bring your IT team. We speak their language.

The fastest version of this conversation includes whoever runs your identity systems. They will have questions; we like those.