Autothenticator Business and Enterprise

Autothenticator · Updated 18 October 2026

Two modes

Moving from Business to Enterprise needs no migration. The key service joins each member's vault as one more device.

Sign-in and people

• Sign-in through the organisation's identity provider, over OpenID Connect: its own app registration, or Entra ID and Google Workspace connected with one admin sign-in.
• Verified domains: the organisation proves its domains with a DNS record. Sign-ins from those domains become work accounts.
• SCIM 2.0 adds and removes people automatically. Users become people and groups become teams.
• Licences are per person. Each active member uses one licence. Sync stops at once, with no grace period, when someone is suspended or removed.

Work and personal installs

• Every account is either work or personal, decided when it's added, and it can't change.
• A work account shows it: the organisation's name, a work badge, and "Your organisation can recover this vault" (Enterprise).
• Installs pushed by company device management are work-only. That covers Intune or other MDM, an Android work profile, a managed iOS app, or Chrome and Edge enterprise policy.
• A personal install can hold work accounts beside the personal one. The organisation can require its own install instead.
• Managed configuration arriving on a browser that already has a personal account never merges the two. The personal vault becomes read-only and can be exported, and the person is told to move it to a personal profile.

Policies

Signed by the organisation and checked on each device. Winfrasoft can't loosen them.

Deployment packages: the console and the key service write ready-made configuration for Chrome and Edge (JSON and a registry file), Intune, Group Policy, Android and Apple device management (Jamf, Intune, Kandji). They can force-install the extension and pin the organisation's keys.

Shared team accounts

For one 2FA account several people need: a helpdesk mailbox, social media, a domain registrar, a cloud root account.

• Roles: Fill only (the default: members can fill it but never see the code) or View (team managers: can see and copy).
• Sites are locked: admins set exactly where the code may be filled, and members can't change it.
• Same 30-second window: many services refuse the same code twice. If a teammate just used this code, the app says "Code just used by Sam: next code in 12 s" and fills the next one.
• Leavers: removing someone makes a new team key without them. The console lists every shared secret they could open (the exposure list), and guides changing each one at the service.
• Machine restriction: an account can be limited to named machines (helpdesk PCs, build PCs, kiosks). Its key is encrypted only to those machines, so a copied vault can't open it anywhere else.
• HOTP isn't allowed in shared accounts, because counters go out of step between people.
• Where they're managed: in Enterprise, shared accounts are created on the key service's own screens. The secret never reaches a Winfrasoft web page.

Admin console

At portal.autothenticator.com/admin.

• Pages: Overview, People, Teams, Devices, Shared accounts, Policies, Audit log, Reports, Settings, Licences.
• Roles: Owner, Admin, Team manager, Helpdesk, Auditor.
• It handles no keys. It manages people, devices and settings, and drafts policy, but it can't open a vault. Every job that needs a key runs on a member's device or on the company key service.

Audit and SIEM

• What's recorded:

  • code filled, copied or shown;
  • fill refused, and lookalike warnings;
  • passkeys made, used and deleted;
  • devices requested, approved and removed;
  • policy changes.

  Each event says who, which account, which device, which website and when. It never includes a code or a secret.

• Where it goes:

  • export to CSV;
  • an API that SIEMs pull from;
  • pushed to Microsoft Sentinel;
  • pushed to any HTTPS webhook, signed with HMAC-SHA256. Splunk and syslog collectors use the webhook or the API.

• Trust: the log comes from the apps, so it's as trustworthy as the devices that report it.

The company key service (Enterprise)

• What it is: a Windows program (a service plus an admin window) the customer runs anywhere: a laptop, a cloud VM or an on-premises server. Winfrasoft never runs one or holds its keys.
• Where it keeps keys: in the machine's TPM (the default; a virtual machine's virtual TPM works too), or in a hardware security module (HSM) connected through Windows CNG or PKCS#11, including cloud HSMs such as Azure Managed HSM. A software store exists for evaluation only, and says so on every screen.
• What it does:
  • creates new members' work vaults;
  • approves devices (with a code, or automatically for managed devices);
  • recovers people who lost every device;
  • holds team keys and creates shared accounts;
  • signs the organisation's policy.
• Connections: outbound HTTPS only. No open firewall ports and no public address.
• The member's say: before letting a key service into a vault, an unmanaged install asks the member. It shows an organisation code that IT can publish (on the intranet, say), so members can check it's really their company's.
• Several key services can run side by side, for resilience.
• Organisation recovery kit: printed at setup, for if every key service is lost. Store it like the company's most sensitive documents.
• Updates are signed by Winfrasoft, and installed only when an admin chooses.
• Two-person rule (optional): recovery and other sensitive jobs need a second admin to approve.