The moment you issue a Multi-Factor Authentication (MFA) provisioning key, the security clock starts ticking. That key is the handshake between your identity backend and the user’s authenticator app. Treat it with the care of a credential that can open the door to your entire system.
An MFA provisioning key, often provided as a URI or QR code, encodes the shared secret used to generate Time-based One-Time Passwords (TOTP) or HMAC-based (HOTP) tokens. This secret must be generated securely, delivered only over encrypted channels, and stored according to a zero-trust principle. For TOTP, the shared secret works with the current timestamp to yield short-lived codes. For HOTP, it syncs with a counter. The provisioning key is the root from which these values are derived.
Provisioning keys should never be reused between accounts, sessions, or devices. Use a cryptographic RNG to generate them. Transmit them only after strong user verification, and bind their lifecycle to the provisioning event. In an ideal flow, the key lives only in memory until it reaches the client, then is wiped from the server. If your provisioning logic logs the key, caches it, or leaves it in browser memory, you’ve introduced a breach waiting to happen.
During MFA setup, provisioning keys are often wrapped in an otpauth:// URI. This format includes the account name, issuer, algorithm, digits, and period parameters. Ensuring these parameters match your authentication policy is critical. For example, if your MFA policy is SHA256 with 8 digits but you provision using SHA1 and 6 digits, users will fail at login without clear error feedback.