TOTP in a separate application
Keeping TOTP in a separate application identifies one factor-location choice, but location alone does not establish a universal security conclusion or a complete setup and recovery model.
Not legal advice. This page is research, not compliance guidance.
What separating TOTP from a password vault changes
Separating TOTP from a password vault changes where the second factor is managed, but the accepted evidence does not establish that separate placement is universally safer or define a complete authenticator-application location model.
Factor location is not one undifferentiated question. Passkeys and Second-Factor Location documents several distinct boundaries for passkeys: cryptographic keys are used from an end-user device, a synced passkey is synchronized through a cloud service, and a device-bound passkey remains on one device. The same reference expressly says that its evidence does not establish a complete location taxonomy for authenticator applications, SMS codes, push approvals, or every hardware factor.
That distinction matters because a location label does not answer every dependency question. The passkey evidence separates key use on an end-user device, cloud synchronization of a synced passkey, and a device-bound passkey that remains on one device. It does not establish how a TOTP application handles any of those relationships, and it cannot be transferred into a conclusion about TOTP setup or recovery.
A separate authenticator application therefore identifies an arrangement to evaluate, not a threat-model-independent result. The accepted sources do not establish whether a named application synchronizes factor material, how it behaves after device loss, what recovery dependencies it creates, or whether an integrated password vault would produce a better or worse outcome. Those questions remain unresolved unless evidence for the particular arrangement answers them.
The defensible comparison stays narrow. One arrangement places password and TOTP management in different applications; another may place them in one system. That description does not show how either system stores, synchronizes, exports, restores, or protects the factor. It also does not show what happens when one device, service, or account becomes unavailable. Separating the applications changes the location map while leaving the setup and recovery model to separate evidence.
Record the factor location without copying the factor
A compartment index can record where a second factor is managed without copying recovery material or a factor seed into the index, but that pointer does not secure, back up, or restore the factor.
Use a Privacy Vault as a Compartment Index presents a bounded editorial model for recording maintenance information. In that model, a central index includes a second-factor location pointer among its maintenance fields. The pointer identifies where the factor is managed without copying recovery material or a factor seed into the index.
A pointer and the material it describes are different things. The pointer supports later review by naming a location or category; it does not become the factor, a copy of the factor, or a recovery method. The source does not claim that recording the pointer proves the factor is available, current, recoverable, or protected. It also does not prescribe where any excluded material should be kept.
This boundary prevents the index model from being mistaken for a TOTP procedure. The accepted evidence does not establish what wording a particular product uses for a factor, whether a location refers to one device or a synchronized service, or which account controls access to that location. The index model supplies a place for a bounded pointer, not the missing product or account details.
The pointer also does not establish independence. The accepted sources do not establish whether two applications depend on the same device, service, account, or recovery path, or whether any specific TOTP arrangement shares those dependencies. Conversely, two functions appearing in one system do not, by that fact alone, establish the details of their custody or recovery. The source-bounded statement is only that the editorial index may identify where the second factor is managed without copying the factor material into the central index.
For this page, the location pointer is useful as a descriptive boundary. It keeps the question of where TOTP is managed separate from the unsupported questions of how it was enrolled, whether it can be transferred, what survives device loss, and what restores access. A recorded pointer can show where to begin a later review; the evidence does not turn that pointer into proof that the arrangement works or that it fits every threat model.
Setup and recovery remain separate evidence questions
The accepted evidence does not establish a TOTP enrollment, backup, transfer, device-loss, re-enrollment, recovery-code, or account-recovery procedure for either a separate application or an integrated password vault.
The general factor-location reference stops before classifying authenticator applications, and the compartment-index model stops at a location pointer. Together, those boundaries leave the operational behavior of TOTP unresolved. They do not say how a TOTP factor enters an application, what material the application retains, whether another device receives it, or what evidence would be needed to restore the same factor later.
Setup and recovery also answer different questions. A description of where a factor is managed does not establish how enrollment occurred. A description of enrollment does not establish what survives the loss of a device or account. A recovery option, if one exists, does not by itself establish whether the factor remains independent of the password system. None of those mechanics may be filled in from a product label or from the passkey evidence.
The unresolved categories below are evidence questions, not setup instructions. Each remains unanswered for this page because no accepted source establishes the behavior for a named TOTP application, password vault, plan, platform, synchronization mode, or recovery path.
- Enrollment boundary: the accepted sources do not establish how TOTP factor material is introduced into either arrangement.
- Custody boundary: the accepted sources do not establish which device, application, service, or account retains factor material.
- Synchronization boundary: the accepted sources do not establish whether a TOTP arrangement synchronizes across devices or services.
- Transfer boundary: the accepted sources do not establish a universal method for moving a factor between applications or devices.
- Device-loss boundary: the accepted sources do not establish the outcome when a device holding or accessing the factor becomes unavailable.
- Recovery boundary: the accepted sources do not establish a backup, restoration, re-enrollment, recovery-code, or account-recovery procedure.
- Comparison boundary: the accepted sources do not establish that separate or integrated management is universally preferable.
These non-findings prevent a location description from becoming a procedure by implication. A reader can identify that TOTP is managed in a separate application and can record a pointer to that location. The evidence still does not establish how the arrangement was created, what dependencies it carries, or how access would be restored.
The same restraint applies to an integrated vault. This page does not establish its storage, synchronization, device, or recovery behavior either. Without accepted evidence for those mechanics, the comparison cannot support a universal security conclusion. The supported result is a clearer set of questions and a visible boundary around what the available sources do not answer.
Limits and non-findings
This reference does not establish a universal TOTP setup or recovery procedure, a product comparison, a device-loss outcome, a passkey-to-TOTP inference, or a universally preferable factor arrangement.
No accepted source establishes a universal method for backing up, exporting, transferring, or restoring a TOTP factor across applications or devices. No enrollment sequence, emergency-access method, re-enrollment process, recovery-code practice, or account-recovery path is established here. The absence of those findings cannot be converted into a procedure or filled with assumptions about common product behavior.
No accepted source establishes that a separate authenticator application is safer than an integrated password vault for every threat model. Separate application names do not establish separate devices, accounts, services, synchronization systems, or recovery dependencies. Integrated management likewise does not establish the details of custody, synchronization, availability, or recovery. This reference does not compare named products or make a universal separation conclusion.
The passkey evidence remains limited to the relationships it actually documents. It distinguishes cryptographic-key use on an end-user device, cloud synchronization of a synced passkey, and a device-bound passkey that remains on one device. It also expressly says that the evidence does not supply a complete location taxonomy for authenticator applications. Those passkey relationships illustrate why location questions should be separated, but they do not answer TOTP product or recovery questions.
The compartment-index evidence is limited as well. It presents an editorial model in which a location pointer can identify where a second factor is managed without copying recovery material or a factor seed into the central index. It does not prescribe TOTP enrollment, backup, synchronization, export, restoration, emergency access, or storage. It does not claim that a pointer protects the factor or that material outside the index is safe.
A narrow conclusion survives these limits: factor location, setup, and recovery are separate evidence questions. A separate TOTP application changes the location description, while the accepted sources leave the arrangement's operational and security consequences unresolved. Any broader conclusion requires evidence about the particular applications, devices, accounts, synchronization relationships, and recovery paths being evaluated.
Frequently asked questions
Is a separate TOTP application always safer than a password vault?
No universal conclusion is established. The accepted evidence distinguishes factor-location questions but does not compare separate and integrated TOTP arrangements across every threat model.
What can a compartment index record about TOTP?
The cited editorial model allows a second-factor location pointer that identifies where the factor is managed without copying recovery material or a factor seed into the index.
Does a factor-location pointer back up or restore TOTP?
No. A location pointer identifies where a factor is managed; the accepted evidence does not establish that the pointer secures, backs up, transfers, or restores the factor.
Does passkey evidence define how authenticator applications work?
No. The cited passkey reference explicitly says its evidence does not establish a complete location taxonomy for authenticator applications, SMS codes, push approvals, or every hardware factor.