Back to Help Center

Login Security and Account Recovery

How PracticeRunner handles passkeys, email links, Google and Microsoft sign-in, physical security keys, recovery codes, and organization login policies.

PracticeRunner supports phishing-resistant sign-in with WebAuthn, including both passkeys and external FIDO2 security keys such as YubiKey.

This article covers staff and practice account sign-in first. Client portal passkeys are handled separately from staff accounts.

What sign-in methods are supported?

PracticeRunner can support:

• Passkeys for device-based or synced WebAuthn sign-in
• Physical security keys for external FIDO2 authenticators
• One-time email sign-in links for authorized staff accounts
• Google sign-in where the deployment allows it
• Microsoft sign-in where the deployment allows it

Available sign-in methods are managed at the system level. Organization security settings define which enabled methods satisfy that practice’s sign-in policy.

Provider, admin, and staff accounts are not open signup accounts. A practice user starts from a PracticeRunner onboarding email or invitation, then adds an allowed sign-in method to that already-authorized account. Google and Microsoft sign-in are authentication methods for those authorized users, not a way for an unaffiliated person to create provider/admin access.

How do client portal passkeys work?

Client portal passkeys are separate from staff passkeys.

Clients first access the portal with the usual secure email link. After they have a full portal session, they can open Account security in the portal and add a passkey for future sign-ins.

A client passkey can use a familiar device unlock method, such as Face ID, Touch ID, Windows Hello, a phone screen lock, a fingerprint, or a physical security key. On the portal sign-in page, clients can choose Continue with passkey as a separate option from email-link sign-in.

Email links remain available for first-time access and as a fallback. This is important for clients who are on a new device, are not comfortable with passkeys, or need help from the practice.

PracticeRunner only allows passkey enrollment after a full portal sign-in. Clients cannot add passkeys from secure message-only links, invoice payment links, or other limited-purpose portal sessions.

The existing portal rules still decide what a client can access, including whether portal access is enabled, whether the client is active, representative access, limited access grants, child client restrictions, and portal terms acceptance.

Why does PracticeRunner emphasize passkeys and security keys?

As of June 24, 2026, HHS still describes the HIPAA Security Rule update as proposed rulemaking and states that the current Security Rule remains in effect while that process continues. The proposal includes stronger security controls, including multi-factor authentication.

PracticeRunner therefore treats phishing-resistant authentication as a strong security control for HIPAA-oriented deployments, especially for privileged users and organizations handling sensitive clinical data.

PracticeRunner was designed passkey-first because strong security should not require more login friction. A passkey is tied to the real PracticeRunner site and uses public-key cryptography, which makes it resistant to phishing. Passkeys also avoid text-message codes and the weaknesses associated with phone-number takeover and SIM-swap attacks. For most users, sign-in is the same familiar Face ID, Touch ID, Windows Hello, device PIN, or security-key action they already use to unlock a device.

References:

• HHS HIPAA Security Rule NPRM: https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/
• HHS Security Rule NPRM Fact Sheet: https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/
• NIST SP 800-63B Authenticator Guidance: https://pages.nist.gov/800-63-4/sp800-63b/authenticators/

What is the difference between a passkey and a security key?

• A passkey is usually stored by your device platform or passkey manager, such as Windows Hello or another compatible passkey provider.
• A security key is a separate physical authenticator, such as a YubiKey, that you insert or tap during sign-in.

Both use WebAuthn, but a physical security key is generally the stronger option for privileged accounts because it is easier to keep separate from the device being used to sign in.

Can my organization require passkeys or security keys?

Yes. Organization owners can configure sign-in requirements in Settings → Practice → Security:

• Require staff to set up a passkey or security key
• Require physical security keys for owners
• Require physical security keys for all users
• Allow staff to request email sign-in links

The passkey setup requirement accepts WebAuthn authenticators such as Face ID, Touch ID, Windows Hello, synced passkeys, and physical FIDO2 security keys. Staff must enroll one before completing setup. The separate email-link setting controls whether staff can request a one-time sign-in email. Practices that already required passkeys keep email sign-in disabled until an owner enables it.

The physical security key requirements are stricter. They require an external key such as YubiKey. Synced or device passkeys do not satisfy a physical-key requirement.

If the all-users physical-key setting is enabled, the passkey or security key requirement and the owner requirement are also enabled automatically. The owner-only physical-key setting applies to owners only; other users follow the all-users passkey or security key setting if it is enabled.

The email-link control is disabled when physical keys are required for all users. Under an owner-only physical-key policy, owners still need their external key even if email links are allowed for other staff.

Review Current policy summary, then save the settings. These practice settings govern staff sign-in; client portal sign-in is managed separately.

Organizations often use the owner-only policy first, then extend it to all users if needed.

What happens to Google or Microsoft sign-in?

When there is no organization-level passkey or security-key requirement, users can sign in with any method that is enabled for the PracticeRunner environment.

When a practice requires passkey setup, Google and Microsoft sign-in are unavailable. Email-link sign-in can remain available if the owner separately enables Allow staff to request email sign-in links. Physical-key requirements still require the enrolled external key for sign-in.

When an organization requires a physical security key, PracticeRunner asks the user to sign in with an enrolled external security key before entering the app.

Microsoft sign-in uses basic OpenID Connect login scopes for provider/admin authentication. It does not add Microsoft calendar, mail, or directory access.

How does account recovery work?

If you cannot use your passkey, contact a practice owner or admin. They can open Settings → Administration → Staff, edit your details, and choose Recover access.

The dialog clearly identifies the saved email address and the 15-minute link lifetime:

• Send by email sends the link to the saved staff email address.
• Copy recovery link lets the owner or admin send it by text or through their own email app.

The link can be used once. Creating another link replaces the previous one. Opening it gives access only to recovery, where you set up a new passkey or security key before entering the app. Existing credentials are not removed merely because someone creates a recovery link.

Recovery requires an active staff account and a valid saved email address. Confirm the staff member’s identity before sharing a link, and share it only with them. If copying fails, use Send by email instead.

For staff who have not signed in yet, use Resend invite in Open Invitations instead. Initial invitations retain their longer setup window.

Accounts that require physical security keys

Recovery must satisfy the physical-key requirement. Enroll a new external key, and save recovery codes if none are available. At least one physical key is required; two separate keys are strongly recommended.

Saved recovery codes remain one-time use. If no practice owner or admin can sign in, contact PracticeRunner support. A system administrator can issue the same single-use, 15-minute recovery link even when practice email sign-in is disabled.

System administrators can review the account’s current sign-in methods and either keep them or explicitly clear them before issuing the link. Clearing also removes saved recovery codes and signs out active sessions. Recovery still requires enrolling a new passkey or security key that satisfies the practice policy.

When email sign-in is disabled

Staff cannot request an email sign-in link from the login page. A practice owner or admin can still issue a short-lived recovery link through Recover access. This does not enable ordinary email sign-in or remove the practice’s key requirements.

What gets audited?

PracticeRunner records both successful and failed login attempts.

For supported authentication flows, audit records can include:

• event type
• user and role
• authentication method
• IP address
• user agent
• relying party ID
• WebAuthn evidence when available

Recovery link issuance, recovery-code use, and authenticator enrollment or removal are also audited.

What should users do if they replace a key or device?

• Remove the old authenticator from Settings → Account → Account Security so it can no longer be used for PracticeRunner.
• If you want the credential removed from the hardware key or passkey manager too, delete it there separately.
• If your account is under a physical-key policy, enroll the replacement key before removing the old one whenever possible.

Are all staff required to sign legal documents?

No. Organization-level legal agreements such as the BAA and Terms of Service are signed by the organization owner or another authorized signer. Workforce members usually do not need to sign those organization contracts individually.

If an organization wants workforce-level compliance evidence, the better control is staff training and policy acknowledgement rather than asking every staff user to sign the BAA.