The brief: phishing-resistant, not just MFA
An AI software company came to us with a hard requirement and a tight deadline. Their own customer was asking for phishing-resistant multi-factor authentication across the systems used to access their data, and it was heading into a contract. Ordinary MFA was not enough. One-time codes, SMS and tap-to-approve push prompts all still rely on a shared secret or a human decision an attacker can relay, and that is exactly what modern phishing kits are built to defeat.
The scope was roughly 110 staff accounts on Google Workspace and an 86-member GitHub organisation. We delivered the Google side inside a single committed week, with GitHub following immediately behind, both under one fixed-price statement of work.
Why we enforced it at the Google layer
Almost everything this organisation used signed in with "Sign in with Google". That is the lever. Rather than onboarding dozens of applications one by one, we put Okta in front of Google Workspace as the identity provider and enforced phishing resistance at the Google authentication event itself. Every app that used Google to log in inherited the stronger control without a single application being modified.
The enforced factor is Okta Verify with FastPass, configured to require a biometric on every authentication. We deliberately removed the weaker options as acceptable factors: TOTP, SMS and standalone push were all excluded, so there was no quiet fallback to something phishable.
What phishing-resistant really means here
In place of a password or a code, each person authenticates with a cryptographic credential generated and held device-bound in their device's secure hardware, the Secure Enclave on a Mac, the TPM on Windows. The private key never leaves the device, and it is only released after the user verifies themselves with Touch ID, Face ID or a device PIN.
That is two factors in one gesture: possession of the enrolled device, proven by a key that cannot be copied off it, and the user's own biometric. Because the credential is cryptographically bound to the organisation's Okta tenant, there is no shared secret for a fake login page to capture and nothing for an adversary-in-the-middle to relay. It defeats credential phishing by design and meets NIST AAL3 on properly configured devices. No hardware tokens to buy and post, and no corporate credential ever synced to a personal cloud account.
This is the same Secure Enclave and Touch ID foundation that Apple's Platform SSO is built on, which we wrote about in Platform SSO on macOS 27.
GitHub: a second front
GitHub does not offer "Sign in with Google", so it needed its own integration. We placed the GitHub organisation behind Okta SAML single sign-on and reused the same phishing-resistant authenticator policy, which meant developer access landed on exactly the same security bar as everything else. That required an upgrade to GitHub Enterprise Cloud, handled by the client directly with the vendor.
The detail that keeps developers productive: existing SSH keys and personal access tokens keep working once their owner completes a one-time SSO authorisation of each one. We audited every token, key and machine account against the organisation's repositories first, so anything that would break at enforcement was a deliberate, known decision rather than a surprise on cutover day.
Rolling it out without breaking everyone's morning
A security control nobody can use is not a win. We ran this as a staged rollout: build with no user impact, an enrolment window with daily reporting and named escalation for stragglers, a small pilot cutover to validate real workflows including mail clients and developer command-line tools, then the organisation-wide switch with a staffed support window on the day.
Recovery was designed in from the start, not bolted on after. The handful of super admin accounts that sit outside SSO by Google's own design were treated as a documented, compensated exception, secured with passkeys and a written recovery procedure. That break-glass thinking is the part most rollouts underrate, and it is the same lesson we cover in why passkey rollouts fail on recovery, not cryptography.
The evidence pack
Because this existed to satisfy a contractual requirement, proof mattered as much as the configuration. We delivered an evidence pack for both workstreams: the Okta authenticator policy export, the enforcement configuration, an enrolment completion report, and a documented register of exceptions with their compensating controls. The client could hand that straight to their own customer as evidence the control was real and enforced.
If you want the same outcome for your organisation, here is how we approach an Okta rollout, and it pairs naturally with SSO and identity management if you are standardising your whole login experience at the same time.