Imagen2: images/neither-passwordless-nor-mfa-secures-ci-cd-alone-2.webp
Schema_json: {"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://zerotrustexplained.com/neither-passwordless-nor-mfa-secures-ci-cd-alone/#article","headline":"Neither Passwordless nor MFA Secures CI/CD Alone","description":"2 identity types decide Passwordless vs MFA for Developer Workflows: people need passkeys; CI/CD needs short-lived OIDC tokens.","datePublished":"2026-07-26T12:00:00+00:00","dateModified":"2026-07-26T12:00:00+00:00","author":{"@type":"Person","name":"Alan White","url":"https://zerotrustexplained.com/author/alan-white/"},"publisher":{"@type":"Organization","name":"Zero Trust","logo":{"@type":"ImageObject","url":"https://zerotrustexplained.com/images/logo.png","width":200,"height":60}},"image":{"@type":"ImageObject","url":"https://zerotrustexplained.com/images/neither-passwordless-nor-mfa-secures-ci-cd-alone.jpg","width":1200,"height":630},"url":"https://zerotrustexplained.com/neither-passwordless-nor-mfa-secures-ci-cd-alone/","mainEntityOfPage":"https://zerotrustexplained.com/neither-passwordless-nor-mfa-secures-ci-cd-alone/","inLanguage":"en","articleSection":"Advanced","about":{"@type":"Thing","name":"Identity security for developer workflows"},"mentions":[{"@type":"Thing","name":"Passkeys"},{"@type":"Thing","name":"FIDO2"},{"@type":"Thing","name":"OIDC tokens"},{"@type":"Thing","name":"Zero Trust"},{"@type":"Thing","name":"WebAuthn"}],"keywords":"passwordless authentication, multi-factor authentication, developer workflows, passkeys, FIDO2, OIDC, CI/CD, Zero Trust, phishing resistance, risk-based MFA, short-lived tokens"},{"@type":"BreadcrumbList","@id":"https://zerotrustexplained.com/neither-passwordless-nor-mfa-secures-ci-cd-alone/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://zerotrustexplained.com/"},{"@type":"ListItem","position":2,"name":"Advanced","item":"https://zerotrustexplained.com/category/advanced/"},{"@type":"ListItem","position":3,"name":"Neither Passwordless nor MFA Secures CI/CD Alone","item":"https://zerotrustexplained.com/neither-passwordless-nor-mfa-secures-ci-cd-alone/"}]}]}
Your IAM renewal has become a false choice: passwordless or MFA for every developer, tool, and pipeline. That model leaves gaps. A passkey cannot authenticate a CI runner. Legacy MFA prompts expose engineers to phishing, push fatigue, and disruptive access friction. One weak exception can bypass strong controls. Examples include an SSH key, static cloud token, or overprivileged service account.
Passwordless vs MFA for Developer Workflows: Which to Choose? Choose passwordless as the default for human access. Passkeys and FIDO2 hardware keys remove reusable passwords and resist phishing. Keep risk-based MFA step-up for production deployments, privilege changes, and secret access. For CI/CD and workloads, use short-lived OIDC identities. Do not use passkeys, passwords, or static API keys for automation. Map controls across Git, SSH, CLI, IDE, cloud, and production.
Choose passkeys plus risk-based MFA, not either/or
Passwordless is usually the best default for human developer access. Passkeys and FIDO2 security keys remove reusable passwords and block most phishing pages. MFA still has a role for high-impact actions. Examples include production deployments and secrets-vault reads.
A FIDO2 passkey or hardware key can meet phishing-resistant MFA goals. It requires device possession and local user verification. A fingerprint stays on the device. It is not sent to GitHub, Okta, Google, or Microsoft.
Use it for production releases, IAM permission changes, and new access-token creation. Use it for secrets export and emergency access. This follows Zero Trust. Access checks depend on the request, device, and risk. One login does not grant access forever.
Strong daily access should not mean permanent high-risk access.
A practical default is simple: require a passkey for daily SSO. Require a fresh hardware-key or passkey check for production, permissions, or secrets.
Elige esto si: your developers use cloud consoles, Git repositories, VPN or ZTNA, and SaaS tools. You must also be able to enforce WebAuthn through an identity provider.
Phishing resistance should decide the human default
Passkeys and hardware security keys are the safest human sign-in methods. They bind each authentication response to the real website. SMS, email codes, TOTP codes, and push prompts reduce some attacks. Attackers can still relay or abuse them in real time.
| Method | Phishing resistance | Typical user cost | Best use in developer access |
|---|
| SMS OTP | Low, vulnerable to SIM swaps and relay | Often included, carrier fees vary | Temporary recovery only, not admin access |
| Email OTP | Low, depends on mailbox security | Usually included | Low-risk fallback during migration |
| TOTP app | Medium, codes can be relayed | $0 to $10 per user monthly | Legacy fallback with short sunset date |
| Push approval | Medium, exposed to fatigue attacks | Often in IdP licenses, about $3 to $15 per user monthly | Conditional backup with number matching |
| Synced passkey | High, origin-bound WebAuthn | Usually included with device ecosystem | Daily SSO for developers |
| Hardware security key | High, origin-bound and controlled device | About $25 to $85 per key | Admins, production, and break-glass |
TOTP is a time-based one-time password. It is usually a six-digit code that changes every 30 seconds. It stops credential stuffing, where attackers test stolen passwords at scale. It does not stop a fake site that captures passwords and codes together.
Hardware security keys give the organization tighter control for privileged roles. They help when a cloud administrator needs a company-issued device. They also help when personal device sync is prohibited. A PAM system can also grant just-in-time production access.
Phishing resistance matters most when access can change production.
Elige esto si: phishing, exposed credentials, or MFA fatigue prompted the project. You need a clear security upgrade over password plus TOTP.
Human developer tools need different controls. Git access, SSH administration, cloud consoles, and production releases have different risks. Use passkey-backed SSO for routine work. Add device trust and step-up rules as potential harm rises.
Controls for git, IDE, SSH, and CLI
Git and browser-based IDE access should use SSO with WebAuthn passkeys. Restrict PATs to named repositories and narrow scopes. Set lifetimes between 30 and 90 days when a token remains unavoidable.
Controls for cloud and production actions
Cloud consoles in AWS, Google Cloud, and Microsoft Azure should require passkey SSO for entry. Require fresh authentication for IAM role changes and access-key creation. Also require it for KMS key changes, billing changes, and production account entry.
Developer access path: match control to impact
Daily work
Git, IDE, docs
Passkey SSO
Elevated work
Cloud CLI, SSH
Passkey + device trust
High impact
Prod, IAM, secrets
Fresh step-up + JIT role
Automation
CI/CD, bots
OIDC short-lived identity
Elige esto si: your team needs different protection for Git, SSH, CLI, cloud, and production. Do not force one MFA prompt into every task.
A usable developer identity policy should map protocols to workflows. It should not map controls only to sensitivity levels. Use passkey-backed SSO for browser Git, IDEs, VPN, Zero Trust access, and cloud consoles.
Use short-lived HTTPS credentials for command-line Git. You can also use SSH certificates from an identity-aware SSH CA. Use FIDO2-backed SSH keys or just-in-time SSH certificates for server administration.
For cloud CLI access, federate through the IdP for short-lived role credentials. Do not store access keys in local profiles. The most frequent error here is treating browser login as full protocol protection.
Browser WebAuthn does not automatically secure native Git, SSH, or CLI protocols. Those tools need a compatible credential-issuance path.
Give CI/CD and workloads identities, not MFA prompts
CI/CD pipelines, bots, service accounts, and workloads need OIDC workload identity. Use short-lived tokens, narrow permissions, and context checks. Interactive MFA is for people. Automation needs an identity that works without a person approving a prompt.
A production pipeline should exchange its OIDC token for a narrowly scoped cloud role. It should not store an AWS access key. It should not store a Google service-account JSON key or Azure client secret in repository variables.
Inventory API keys in source repositories, CI variables, secrets managers, developer laptops, and vendor tools. Revoke exposed keys first. Then replace each use with OIDC, managed workload identity, or a secrets broker. A secrets broker rotates credentials automatically.
Give each bot its own identity and purpose. A build bot should not read production secrets. A release bot should not alter IAM policies.
Machine access needs proof of workload context, not human MFA.
Elige esto si: you run CI/CD, Kubernetes workloads, bots, or integrations. You want to remove static keys without breaking unattended jobs.
Short-lived OIDC tokens are safe only when cloud trust policies validate workload context. Checking only the token issuer is not enough. Bind each CI/CD role to a specific issuer and audience.
Also bind it to a repository or project. Bind it to an immutable workflow identity, protected branch or tag, and deployment environment. Deny pull-request and forked-repository events from assuming production roles.
A release role can require tokens from an approved release workflow. It can also require a signed tag and the production environment. This works well in theory, but broad trust rules often undo it.
Log every token exchange and review unused trust relationships often. These controls make service-account security enforceable. They also stop broad pipelines from gaining broad short-lived credentials.
Use step-up policies and migration plans together
Risk-based step-up controls protect sensitive actions without making every sign-in painful. Phased migration prevents lockouts during a move from passwords and TOTP. Ask for more proof only when request, device, or session risk requires it.
Actions and signals that require step-up
Require fresh verification for production deploys and rollback approval. Also require it for secret reads, privilege elevation, new PAT issuance, and conditional-access policy changes. For SOC 2, ISO/IEC 27001, HIPAA, or PCI DSS evidence, log the user, device, method, action, and decision.
A safe passkey migration sequence
After 30 to 60 days of stable adoption, stop new SMS enrollment. Then retire email OTP and restrict TOTP to controlled recovery. Keep two break-glass accounts per critical environment.
Store their keys separately and limit their privileges. Alert on every use. Test them at least every 90 days.
Recovery planning decides whether passwordless survives a real incident.
This advice does not directly fit estates with only legacy applications. These applications cannot support SAML, OIDC, WebAuthn, or FIDO2. The estate also lacks a viable identity proxy. In that case, prioritize network segmentation, PAM, compensating controls, and gradual modernization. Never use human passkeys to authenticate automated workloads.
Elige esto si: you are replacing password plus TOTP or have remote staff. It also fits teams that need safe recovery from lost devices and production incidents.
Recovery must be designed before retiring passwords and TOTP. During enrollment, require each developer to register a primary passkey. Require a separate backup authenticator too.
The backup can be a second managed device or FIDO2 security key. Verify both before calling migration complete. For lost devices, use a documented help-desk identity-proofing flow.
Require manager or security approval for privileged roles. Use a cooling-off period where appropriate. Revoke the missing authenticator immediately.
Break-glass accounts need named custodians and offline hardware keys. Store keys separately and remove daily-use permissions. Test the process for restoring normal access after an emergency.
This keeps recovery from becoming production security's weakest path.
Questions & answers
Is passwordless better than MFA?
Passwordless is better for routine developer sign-in when it uses FIDO2 passkeys or hardware keys. High-impact actions still need step-up checks based on action and device risk.
Is passwordless considered MFA?
Yes, a FIDO2 passkey can count as MFA. It proves possession of the authenticator and requires a biometric or PIN. Email links without another protected factor do not offer the same assurance.
Can passkeys replace TOTP for developers?
Yes, passkeys can replace password-plus-TOTP for most developer SSO flows. Test recovery and backup authenticators first. During a controlled 30-to-60-day migration, retire TOTP from daily use and retain it only for controlled recovery where necessary.
What should CI/CD use instead of MFA?
CI/CD should use OIDC federation and short-lived workload tokens. These tokens are usually valid between 5 and 60 minutes. A pipeline must never need human push approval, a passkey, or a long-lived API key.
Which model should your organization choose?
Choose passkey-first with risk-based step-up for human developer access. Choose OIDC workload identity for automation. This is the strongest practical choice. It removes reusable passwords without treating routine sign-in like production privilege.
Use hardware security keys for cloud administrators, PAM users, and production break-glass roles. Choose them when device control matters more than convenience. Use synced passkeys for most engineers when managed-device rules, recovery, and cross-device support exist.
Keep TOTP or push only for controlled transition or limited recovery. Do not choose either as the long-term answer when phishing resistance drives the project.
The best model separates human proof from machine proof.
For developer workflows, the decision is not passwordless versus MFA. Use phishing-resistant human access, risk-based step-up for sensitive actions, and short-lived machine identity for automation.
Choose a hybrid model for modern SSO tools and a few legacy systems. Avoid a universal policy. It should not treat pull requests, pipeline deployments, and IAM changes as the same event.
