MFA for homegrown auth: what teams need to govern now

At a glance

What this is: This guide shows how to add MFA to homegrown authentication and identifies the operational controls that matter most once factors, challenges, and secrets enter the flow.

Why it matters: IAM teams should care because MFA only reduces risk when enrollment, challenge lifetime, retry rules, and secret handling are governed as part of the identity workflow.

Context

Homegrown MFA integration is not just an authentication feature change. Once a team starts enrolling factors, issuing challenges, and storing challenge identifiers, it is operating a broader identity control plane with lifecycle, secret-handling, and retry semantics that can fail independently of password login.

The primary governance gap is that MFA often gets treated as a sign-in checkpoint rather than a managed workflow. In practice, factor enrollment, challenge expiry, fallback methods, and secure storage determine whether the added assurance survives real user behaviour and implementation shortcuts.

Key questions

Q: What breaks when MFA is bolted onto homegrown authentication without lifecycle controls?

A: The weak point is not the second factor itself but the state around it. If enrollment, challenge expiry, reuse handling, and secure storage are not governed, MFA becomes a reusable workflow instead of a durable control. That creates replay, stale challenge, and secret-exposure risk even when the login screen appears protected.

Q: Why do SMS-based MFA flows create more risk than TOTP in custom auth systems?

A: SMS depends on a transport channel that can be intercepted through SIM swap, phishing, or malware, so it is weaker as a primary factor. TOTP reduces exposure by keeping the second factor tied to a shared secret and a local authenticator app, which is easier to govern as a controlled identity artefact.

Q: How can security teams tell whether adaptive MFA is working properly?

A: Look for a lower challenge rate on routine sessions, a higher challenge rate on suspicious transactions, and stable or improved conversion. If adaptive MFA is triggering everywhere, it is behaving like blunt MFA. If it rarely triggers on risky actions, the policy is too weak to matter.

Q: When should teams re-enroll or reset MFA factors after a suspicious event?

A: Re-enrollment is appropriate when a device changes, a user reports compromise, or verification patterns suggest abuse such as repeated failed challenges. The goal is to invalidate the existing factor state before an attacker can keep using it. A secure reset path should revoke old factors, not layer a new factor on top of them.

Technical breakdown

Factor enrollment and challenge issuance in a custom login flow

A homegrown MFA flow usually starts with a stored factor identifier, then issues a challenge only when the user has authenticated with the primary method. That means the application must track whether a factor exists, which method it uses, and whether the challenge belongs to the current login session. The guide shows both TOTP and SMS enrolment, but the control boundary is the same: the application has to preserve identity state across separate steps without exposing the secret used to create or verify that state. If enrollment, challenge creation, and verification are not tied together carefully, the flow can be replayed, confused, or bypassed by stale state.

Practical implication: bind factor enrollment and challenge issuance to the same authenticated session and persist only the minimum identifiers needed for later verification.

Challenge expiry, one-time use, and retry control

MFA challenge security depends on lifecycle rules, not just code entry. The article notes that a challenge can be verified only once and that SMS challenges expire after 10 minutes. That makes the challenge a short-lived authenticator with a defined validity window, which reduces abuse but also creates failure modes if the application allows retries after consumption or does not handle expiry cleanly. Rate limiting and cooldown periods matter because repeated verification attempts create brute-force opportunity and user friction at the same time. The operational question is whether the application consumes the challenge on success, rejects stale retries, and cleanly issues a new challenge when needed.

Practical implication: enforce one-time use, short lifetimes, and retry throttling so verification logic cannot be reused as an attack surface.

Secrets storage and factor identifier governance

The article distinguishes between the MFA secret, the challenge code, and the factor identifier, and those objects need different handling. TOTP secrets and SMS codes should never escape controlled flows, while factorId and challengeId must be stored securely for later verification and audit. In a homegrown build, the common failure is not the MFA protocol itself but the surrounding storage and logging layer. If secrets reach logs, debug output, client-side code, or unencrypted storage, the control collapses even when MFA is technically enabled. This is an identity-governance problem because secret lifetime, storage location, and access scope all determine whether MFA actually raises assurance.

Practical implication: treat TOTP secrets, challenge codes, factor IDs, and logs as separate data classes with explicit storage and exposure rules.

Threat narrative

Attacker objective: The attacker’s objective is to bypass or weaken MFA protection so a valid sign-in can proceed without genuine second-factor assurance.

1. Entry begins when the attacker reaches a login flow that accepts weak fallback authentication or poorly governed MFA enrollment paths.
2. Credential access occurs when the attacker can obtain or abuse challenge codes, factor secrets, or reused challenge state from the surrounding implementation.
3. Escalation follows if the application accepts stale, repeated, or weakly rate-limited verification attempts that let the attacker satisfy MFA controls.
4. Impact is unauthorized sign-in or account takeover in sessions that were assumed to be protected by MFA.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA is only as strong as the lifecycle around it: Adding a second factor improves assurance, but the security outcome depends on how enrollment, challenge issuance, expiry, and reuse are governed. A homegrown implementation turns MFA into a stateful identity workflow, not a simple login toggle. The practical conclusion is that teams must treat factor lifecycle controls as part of authentication design, not as after-the-fact hardening.

Homegrown MFA creates factor-state governance debt: Once factorId and challengeId exist, the application has created security objects that need issuance, storage, audit, and invalidation rules. That is a governance burden many teams underestimate because the user experience looks simple while the control surface is not. The implication is that identity teams should review MFA as managed state, with explicit ownership for enrollment, reset, and revocation.

SMS fallback weakens the assurance model: The article itself recommends TOTP over SMS, and that is the right hierarchy for identity assurance. SMS brings carrier dependency, interception exposure, and weaker resistance to phishing and SIM-swapping, which makes it a fallback transport rather than a durable authentication factor. Practitioners should treat SMS as a constrained exception path, not a default control.

Secret storage is part of authentication security, not an adjacent concern: The article’s advice to store secrets as managed secrets and avoid logging is central, not optional. When authentication secrets are exposed in logs or mis-scoped configuration, MFA becomes a visible control with invisible leakage. The key practitioner takeaway is that authentication assurance collapses when secret hygiene is outside the identity programme’s governance boundary.

Named concept: factor lifecycle risk: The real governance problem is not whether MFA exists, but whether factor enrollment, challenge validity, and re-enrollment are controlled across the full lifecycle. That concept matters because homegrown auth often fragments ownership between application teams, platform teams, and identity teams. The practical implication is to make factor lifecycle an explicit control domain with clear ownership and evidence.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Factor lifecycle risk: Homegrown MFA changes the control problem from authentication alone to the full lifecycle of factor enrollment, challenge validity, and secret handling. Teams that do not assign ownership for those objects usually end up with a visible MFA feature and an invisible governance gap.

The strongest design choice is to govern MFA as a stateful identity workflow. That means treating factor resets, challenge expiry, retry logic, and secure storage as first-class controls in the application and IAM programme, not as implementation details left to engineering.

For identity teams, the practical signal is whether MFA evidence can be audited cleanly. If the organisation cannot show who enrolled the factor, when a challenge expired, and how secrets are protected, the control is not mature enough for high-assurance access.

For practitioners

• Prefer TOTP over SMS for primary MFA Use TOTP as the default second factor and reserve SMS only for constrained fallback scenarios. The article is explicit that SMS is not a secure MFA method and should not be the primary option.
• Treat MFA secrets as managed secrets Store the API key, client ID, TOTP secret, and any challenge material as managed secrets, never in logs or client-side code. Keep factorId and challengeId in secured server-side storage only.
• Enforce single-use and short-lived challenges Invalidate each challenge after successful verification and reject expired SMS or TOTP challenges without exception. Build cooldowns and rate limits around repeated verification attempts.
• Log enrollment and verification events Capture enrollment, challenge creation, verification, IP address, user agent, timestamp, and factor method so failed patterns and suspicious re-enrollment can be investigated.
• Re-enroll factors after suspicious activity Provide a secure reset path that invalidates existing factors and forces re-enrollment when device changes, abuse signals, or account recovery events indicate higher risk.

Key takeaways

• Adding MFA to homegrown authentication improves assurance, but the real control surface shifts to factor lifecycle management, not just sign-in mechanics.
• Challenge expiry, one-time use, and secret storage determine whether MFA resists reuse and exposure in practice.
• Teams should govern enrollment, logging, and re-enrollment as part of the authentication design, because MFA fails when those steps are left informal.

Key terms

• Factor lifecycle: The end-to-end management of an MFA factor from enrollment through verification, reset, re-enrollment, and revocation. In homegrown auth, lifecycle control is a security control because factor state determines whether a challenge is valid, reusable, or safely retired.
• Authentication Challenge: An authentication challenge is the response used when a user tries to access a protected resource without being authenticated. It asks the user to prove identity before access continues. In ASP.NET, the active scheme determines how the challenge is issued and what redirect or status response appears.
• Managed Secret: A credential stored and handled through a controlled process rather than embedded in code or exposed to developers broadly. In this pattern, API keys and client IDs still need protection because they can be used to request tokens or interact with the broker on behalf of the application.
• Fallback Factor: A secondary access method used when the primary passwordless factor is unavailable. It can preserve continuity, but it also creates a high-risk exception path if it is not tightly scoped, logged, and revoked after use, which is why fallback design is central to governance.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.