A break glass account in Devolutions Hub Business is a dedicated administrator account used only when normal sign-in paths are unavailable, such as during an SSO outage, a misconfigured identity provider, a provisioning error, or a security incident.
This article describes when a break glass account is required in Devolutions Hub Business and how to set one up to be ready when needed.
Use the break glass account to sign in when the IdP is unavailable, provided Force SSO is not enabled. If Force SSO is enabled, use the application identity and PowerShell procedure to disable Force SSO first.
Examples include a wrong callback URL, a wrong client ID or secret, broken domain verification, an invalid Okta or Entra configuration, or an expired secret. The break glass account lets an admin get back into Devolutions Hub Business to edit, delete, or fix SSO settings, or use the documented PowerShell path if Force SSO blocks normal login.
Force SSO was enabled too early or during a failed migration. This is the highest-risk case. A standard Devolutions Account is not enough if Force SSO blocks all non-SSO sign-ins. The documented recovery mechanism is an application identity with system configuration rights, combined with the script that sets ForceSSOLogin = $false.
If provisioning or deprovisioning from the IdP removes admins or breaks group assignment, a break glass account outside the provisioning scope can restore users and groups. Provisioning automates user and group management. Users who are not managed by the authentication provider can be added only when Force SSO is disabled for all users.
Examples include admins who have left the company, are on vacation, have been disabled in the IdP, or have lost access. Devolutions Hub Business ownership can be transferred to another administrator. Only one owner is allowed, and only administrators can be assigned as owner.
The owner has special status and cannot be deleted. Only current administrators can be set as owners, and we recommends minimizing the number of administrator accounts. A break glass admin provides a controlled way to recover governance without over-provisioning everyday admins.
The break glass account should have independent MFA and stored recovery codes. The Devolutions Account supports two-step verification, alternative verification methods, and sign-in recovery codes. Recovery codes are explicitly described as a last-resort method for accessing the account.
During an identity incident, you may need Devolutions Hub Business access that does not depend on the compromised IdP. This allows you to disable SSO, review users, remove compromised admins, rotate shared secrets, review logs, and preserve business continuity. This is the classic break glass or firecall pattern: emergency access to a secure system when privileged access is otherwise unavailable.
SSO domain verification is mandatory and depends on DNS TXT records. If DNS or domain validation breaks, a break glass admin can access authentication settings and repair the configuration.
Keep the Devolutions Hub Business Recovery key in a safe place. A temporary recovery key is sent when Devolutions Hub Business is created. The owner is then prompted after 30 days to regenerate and download a non-expiring key, and Devolutions Hub Business owners are also prompted to validate the key after six months.
If a security incident requires disabling users, changing admin status, removing vault access, or restoring access for a critical team, the break glass account provides a controlled admin path. In Devolutions Hub Business user management, administrators can change what users are able to do, assign user groups, enable or disable users, and set admin status.
Do not confuse a Devolutions Hub Business break glass account with a PAM break glass or firecall privileged account. The Devolutions Hub Business PAM module governs privileged accounts and supports checkout approval, automatic password reset, secure password injection, administration reports, and logs. These are the appropriate controls for emergency access to servers, Active Directory, Entra accounts, or other target systems.
A break glass account is also useful as a safety net for SSO rollout testing, SSO or SCIM migration windows, validating owner transfer procedures, verifying recovery key storage, testing account-recovery documentation, and proving that emergency access works during audits.
A break glass account should not be used for daily administration.
Use a dedicated account such as hub-breakglass@company.tld rather than a named employee account. Make it a Devolutions Hub Business administrator, but avoid granting it broad vault or content access unless the emergency runbook requires it. Do not assign it as the owner by default unless your governance model requires owner-level fallback. If it must be owner-capable, document who can promote it and when.
Configure MFA with at least two independent recovery paths, store sign-in recovery codes offline, keep the Devolutions Hub Business Recovery key in a safe place, exclude the account from SCIM deprovisioning where possible, and test the login quarterly. If Force SSO is enabled, also create the application identity and store the application key and secret under dual control, so Force SSO can be disabled during a lockout.
Share your feedback