> ## Documentation Index
> Fetch the complete documentation index at: https://help.clinikehr.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Single sign-on
> What ClinikEHR supports today for signing in with an existing identity, and what to use while broader enterprise sign-on is not self-service.
export const Availability = ({editions = ['all'], plans, roles, note}) => {
const list = editions.includes('all') ? ['clinic', 'pharmacy', 'lims'] : editions;
return
Available in
{list.map(e =>
{EDITION_LABELS[e] || e}
)}
{plans ? Plan : null}
{plans ? {plans} : null}
{roles ? Who : null}
{roles ? {roles} : null}
{note ? {note} : null}
;
};
ClinikEHR offers three ways to sign in: a **password**, a **passkey**, and **Continue with Google**. Google is the only external identity provider supported today.
Broader enterprise single sign-on — connecting your own identity provider so it governs who may sign in — is **not something a workspace can configure for itself**. There is no settings screen for it, and adding one is not a workaround you can assemble from what is in the product. If your organisation needs it, [contact support](/platform/help/contact-support) and describe your provider and your requirement, and we will tell you what is available.
## Signing in with Google
**Continue with Google** appears on both the sign-up and the sign-in screens. Select it, choose your Google account, and you are returned signed in.
Two behaviours are worth knowing before you roll it out to a team.
### Signing up with Google finishes on a separate form
The normal sign-up path walks you through a wizard that collects your details and creates your workspace as you go. Google sign-up does not run that wizard. You are signed in first, and then asked to complete your profile on a separate form before you can get to work.
Nothing is lost — you fill in the same details, just afterwards rather than before. Expect it, so it does not look like the sign-up failed.
### Google is refused on an email that already has a password
If an account already exists for that email address with a password, using **Continue with Google** is refused rather than silently merged: "This email is already registered with a password. Please sign in using your email and password instead, or reset your password if you've forgotten it."
That is deliberate. Silently joining an unverified external identity to an existing account is how one person ends up inside another person's records. Sign in with the password, and use the reset link on the sign-in screen if you have forgotten it.
There is no way to convert a password account to a Google account after the fact. Pick one method per person before you invite a team, not after.
## What to use in the meantime
Two things give you most of what people want from enterprise sign-on, and both are available to every workspace today.
A passkey replaces the password with the device's own biometric or PIN. There is no shared secret to steal, and nothing to phish. Set one up per device from your security settings.
An owner can require two-factor for everyone in the workspace. Enrolment cannot be skipped, and patient data will not open from a session that has not passed the second factor.
Between them you get a strong credential and a rule everyone has to follow — which is usually the actual reason an organisation asks for single sign-on.
A passkey counts as **one** factor, not two. In a workspace that requires two-factor, someone signing in with a passkey is still asked for their authenticator code before any clinical screen opens. See [Two-factor authentication](/platform/security/mfa).
## Practical advice for a team
* **Decide the sign-in method before you invite anyone.** Mixing Google and password accounts across one team is what produces the refusal above.
* **Removing access is still done in ClinikEHR.** Even for a Google account, taking someone out of your workspace is what stops them reading your records — disabling their Google account elsewhere does not do it for you. See [Roles](/platform/team/roles).
* **Require two-factor** if you want a rule that applies to everyone regardless of how they sign in.
* **Every sign-in is recorded** as a **Signed In** entry in your [audit log](/platform/security/audit-log), whichever method was used.
## Related
Passwords, passkeys, two-factor and sign-in alerts.
Requiring a second factor across a workspace.
Getting people into your workspace in the first place.
Ask about enterprise sign-on for your organisation.