How to add TOTP two-factor authentication and conditional access policies to your company's internal applications

To add TOTP 2FA and conditional access to internal applications you do not touch each application's code: you delegate login to an identity provider over OpenID Connect and configure the second factor once, at the point where authentication happens. Policies — 2FA disabled, optional or mandatory, session lifetime, failed-attempt threshold, allowed email domains — then apply per tenant, per project and per role, so the admin panel can always require a second factor while the intranet keeps it optional, on the same user base.

What TOTP actually is

TOTP (Time-based One-Time Password, RFC 6238) is an extension of HOTP where the counter is time. The server and the authenticator app share a secret generated once, at registration; at each login both compute an HMAC over the secret and the number of 30-second intervals elapsed since a common epoch, and truncate the result to 6 digits. Nothing but the code travels over the network, and the code expires by itself.

otpauth://totp/Example:jane.doe@example.com
  ?secret=JBSWY3DPEHPK3PXP
  &issuer=Example
  &algorithm=SHA1
  &digits=6
  &period=30

TOTP works offline, does not depend on the mobile network and has no per-message cost like SMS. Above all it is not vulnerable to SIM swap, which is why NIST has treated SMS OTP as a weak factor for years. It does remain exposed to real-time phishing: an attacker who gets the code handed over on a cloned page reuses it within 30 seconds. For the most sensitive applications the next step is origin-bound cryptographic factors, covered on passwordless authentication.

Step 1 — Classify internal applications

What kills MFA projects is not technical: it is enforcing the second factor everywhere on the same day. Classification is how you decide where the friction cost is justified.

Step 2 — Centralise login, not the second factor

If every application implements its own TOTP you get N secrets per user, N recovery flows and N implementations to keep up to date. By delegating login over OIDC, the second factor lives in the identity provider: the application receives a token and does not even know whether the user used a password, a TOTP code or corporate SSO.

import { LoginMaster } from "@loginmaster/sdk";

const lm = new LoginMaster({
  projectKey: process.env.LOGINMASTER_PROJECT_KEY,
  tenant: "https://tenant.example.com",
});

const session = await lm.verifyToken(token);
if (session.valid) {
  // The project 2FA policy has already been applied upstream
  const userId = session.subject;
}

If you use neither TypeScript nor .NET, the same works over REST with POST /v1/auth/verify. SDK details are on Integration. If the internal applications are already federated with Entra ID or Google Workspace, the SSO guide is here.

Step 3 — Enable TOTP with sensible parameters

• Generate the secret server-side with a cryptographically secure generator, at least 160 bits, and show it to the user only once.
• Confirm activation only after the user has entered a valid code: without that check, a user who mis-scanned the QR code is locked out.
• Reject reuse of a code already consumed in the same window: without it, a 30-second replay is trivial.
• Rate-limit attempts per user and per IP address: 6 digits are a million combinations, and an unthrottled automated attack works through them quickly.
• Keep drift tolerance at ±1 interval. Raising it to ±5 'to cut down tickets' stretches the useful window of a stolen code from 90 seconds to five minutes.

Step 4 — Enrollment and recovery: the underrated part

2FA introduces a new problem: what happens to whoever loses their phone. The answer chosen here determines the real security level of the system far more than the cryptographic parameters do.

The common shortcut is to let the helpdesk disable the second factor on request. It is convenient, and it is also the point where the whole MFA investment cancels out: from then on account security depends on an operator's ability to recognise a social-engineering phone call. The best known incidents of recent years went through exactly that door, not through a weakness in the algorithm.

1. 1At registration hand out single-use recovery codes and ask for explicit confirmation that they have been stored.
2. 2Allow more than one device to be registered: it is the most effective countermeasure, because it avoids recovery in most cases.
3. 3Write down the recovery procedure and the verified channels it uses (registered email, confirmed phone number).
4. 4State recovery timings in internal documentation: a secure procedure nobody knows about becomes an urgent ticket on the first Monday morning.
5. 5Log every recovery as a security event and forward it to the SIEM: it is one of the most interesting events to correlate.

Step 5 — Conditional access policies

"Conditional access" means the authentication decision depends on context instead of being a constant. It is worth being precise about what a platform does, because the term covers two different families: declared policies — who accesses what, with which factor and for how long — and risk evaluation based on behavioural signals and machine learning.

LoginMaster implements the first family: deterministic conditions, verifiable and documentable in an audit, declared at tenant, project and role level. It is a deliberate choice, and it is also the family that covers most of the real requirements of an organisation securing its internal applications.

An applied matrix example

Step 6 — A rollout that does not cause a revolt

1. 1Week 1: enforce 2FA on administrative roles. They are few, the most exposed and the most motivated.
2. 2Weeks 2-4: make 2FA optional for everyone, with a communication explaining why and a one-page enrollment guide.
3. 3Week 5: make it mandatory for roles with access to personal or financial data, announcing the date at least two weeks ahead.
4. 4Week 6+: extend department by department, monitoring the enrollment rate and ticket volume.
5. 5Throughout: measure. Completed enrollments, recovery requests, logins failed on a wrong code. If recoveries explode, the problem is communication, not TOTP.

Step 7 — Edge cases to test

• Phone clock 2 minutes out: the code must be rejected with a message suggesting time synchronisation.
• Same code submitted twice: the second attempt must fail.
• Repeated attempts with random codes: temporary lockout must trigger and generate a security event.
• Enrollment interrupted halfway: the user must be able to start again without being stuck in a blocking intermediate state.
• Device lost with recovery codes available: self-service re-entry, no helpdesk involvement.
• User federated via SSO with MFA already enforced by the IdP: no double second-factor prompt.
• Every event above must appear in the authentication log and reach the SIEM.

The last point is not a completeness detail: activation, attempted deactivation and recovery events for the second factor are among the evidence required by ISO 27001 access controls. Event details and export formats are on SIEM integration.

Comparison: what to ask a platform

Nearly every authentication platform offers TOTP. The differences that matter come out in the questions nobody asks during selection, and that become relevant after the first incident.

The extended comparison with individual platforms is in the alternatives hub; the available MFA capabilities are described on adaptive MFA and adaptive authentication.

Who wrote this guide

LoginMaster is the IAM platform of CDBKR S.r.l., an Italian company that designs and operates authentication infrastructure for software houses, MSPs and European enterprise organisations. The criterion applied here — no administrator can act on a user's credentials or second factor — is the same architectural constraint the product is built on, described on Security and zero-knowledge authentication. To assess your own scenario: contact us.