Not generally available. Certificate-based authentication is delivered as a customer-specific configuration, designed and set up together with Flip.
Certificate-based authentication lets an employee sign in with a certificate that your organization has placed on the device, instead of a second factor that lives on a personal phone. It is built for the situation where a one-time-code app or a passkey is not workable: shop floors and production sites where private phones are not permitted, and devices that several people share.
Your certificate authority issues the certificates. Flip is configured to trust that authority. From then on, every certificate it signs works, and every certificate it revokes stops working, with nothing to register on the Flip side.
Availability
This is not a generally available feature. There is no self-service setting to switch on, and the behaviour is not identical for every organization.
What that means in practice:
- Whether it is available for your organization at all is a separate conversation. This page describes the mechanism; it does not mean the feature is ready to order.
- The configuration is agreed with you and built for your environment. Several of the decisions listed under What we decide together have no default answer.
- Scope, timelines and support come from what is agreed with Flip, not from this page.
- This is written so your IT and security teams can assess the approach. It is not a self-service setup guide.
Talk to your Customer Success Manager before you plan around anything described here.
Two ways to use it
The difference comes entirely from what the certificate names. You decide which one you issue, and you can use both in different parts of your estate.
| User certificate | Device certificate | |
|---|---|---|
| The certificate names | One specific person | One specific device |
| Typical use | A device assigned to one worker | A device shared by a team |
| At sign-in | The employee is identified by the certificate | The employee still enters who they are |
| Second factor | A PIN, where you require one | A personal PIN or password |
| Result | Sign-in without typing credentials | Personal sign-in on a shared device, without a personal phone |
The device-certificate case is the one that solves shared devices. Several people use the same device, each signs in as themselves, and none of them needs a phone to do it.
Why this is still two-factor
The most common objection is that removing the one-time code removes a factor. It does not. It moves the possession factor from a personal phone to the device your organization controls.
| Sign-in path | Something you have | Something you know |
|---|---|---|
| Today, on a shared device | Personal phone, for the code or passkey | Password |
| Device certificate | The managed device and its hardware-bound key | PIN or password |
| User certificate | The assigned device and its hardware-bound key | PIN, where you require one |
With a device certificate, the two factors are the device and the employee's own secret. With a personalized certificate, both factors are bound to the person.
The strength of the possession factor depends on where the private key is stored. A key held in device hardware, a security chip or a smartcard cannot be copied off the device, and that is the strong case. A certificate whose key can be exported is considerably weaker. Plan for hardware-backed keys wherever your devices allow it.
What you provide
- A certificate authority. Your own, or one built into your device management. Flip does not issue certificates.
- A way to get certificates onto devices, usually MDM. See the next section.
- A published revocation source, so Flip can check on every sign-in whether a certificate is still valid.
- A decision on issuance policy: who gets a user certificate, which devices get a device certificate, and how long certificates are valid.
How certificates reach the devices
Flip does not care which route you use. It only ever sees a signed certificate.
- Mobile device management, or MDM (the usual route). Common MDM products can request certificates from your certificate authority and install them automatically, storing the private key in device hardware. A policy decides whether a device gets a user certificate or a device certificate.
- Active Directory. On domain-joined Windows machines, standard automatic enrolment does the same job without MDM.
- Smartcard or security key. The certificate does not have to live in software. An employee ID card with a smartcard chip, or a security key tapped over NFC or plugged in, works the same way.
All three end in the same place: a certificate signed by an authority Flip trusts. The trust is configured once, and you choose the delivery method that fits your estate.
A separate sign-in address
This is a technical constraint with a visible consequence, so plan for it.
A server can only receive a certificate if it asks for one while the secure connection is being established, before any page loads. When it asks, the browser shows a certificate picker. Anyone without a certificate would see a confusing prompt.
Flip therefore does not ask for certificates on the normal sign-in address. Certificate sign-in runs on a separate address used only for that purpose, and the normal one stays untouched. In practice:
- On the web, employees reach it through a dedicated entry point, so only people who have a certificate ever go there.
- In the mobile app, routing can happen automatically on managed devices, without anyone having to choose.
What Flip configures
Per organization, and mostly once:
- The trust anchor. Your certificate authority is installed as trusted for your organization only, so it can never be used to sign in to anyone else's.
- Identifier mapping. Which field in the certificate carries the identifier, and how it maps to a Flip user.
- The device rule. How a device certificate is told apart from a user certificate.
- The revocation source. Where to check, and how long a cached answer stays valid.
What we decide together
These have no default. They set your assurance level and the experience on the floor, and they are the substance of the configuration work.
- Which certificate field carries the identifier, and what pattern to expect.
- How a device certificate is recognised as naming a device rather than a person.
- Whether direct sign-in with a user certificate additionally requires a PIN.
- On shared devices: the length of the PIN and the lockout policy behind it.
- What happens when there is no certificate or an invalid one: refuse, or fall back to normal sign-in.
- Whether a device certificate admits any employee in your organization, or only a defined list of people on that device.
- Which devices, operating systems and browsers have to work on the floor.
Limits to plan for
Stated plainly, because your security team will ask.
- The trust follows your certificate authority. Flip trusts what it signs. Issuance discipline on your side becomes Flip's security posture. Scoping the accepted name patterns and binding the trust to your organization alone are the mitigations.
- Revocation is not instant. If Flip works from a cached revocation list, a revoked certificate can keep working until the next refresh. A live check is fresher but adds a dependency on your endpoint being reachable. The interval is a decision, and it should match your risk appetite.
- Flip must be able to reach your revocation endpoint. If it is only published inside your network, connectivity has to be solved before anything else. This is the most frequent practical blocker.
- A device certificate lowers per-person assurance by design. Anyone holding the shared device, with a valid user name and PIN, can sign in. That is the deliberate trade for usability on the floor, and the device certificate plus the PIN keep it at two factors.
- A user certificate without a PIN is possession only. Strong when the key is hardware-bound and cannot be exported, weak when it can. This is why the PIN question above matters.