Glossary
Two-factor authentication
Also called: 2FA, MFA, multi-factor authentication
Two-factor authentication requires a second proof of identity beyond a password, typically a time-based code or a hardware key. In a document system it is the control that makes a stolen password insufficient, which matters because passwords are the most commonly compromised credential.
Two-factor authentication explained
Which factors are worth requiring
Time-based one-time codes from an authenticator application are the practical baseline: widely supported, no per-user cost, and resistant to password reuse and credential stuffing.
Hardware security keys are stronger because they resist phishing — a code can be relayed to an attacker in real time, a key cannot. For roles with administrative authority over a document estate, they are worth the friction.
SMS codes are better than nothing and weaker than both, because SIM swapping and interception are practical attacks. Where a regulator or an insurer specifies "multi-factor", it is worth checking whether SMS satisfies them.
Enforcing it per role
Blanket enforcement is simplest and creates friction for occasional readers. Per-role enforcement is a reasonable compromise: require it for anyone who can approve, administer, change permissions or export, and leave read-only roles to organisational policy.
What matters is that the requirement is a system-enforced setting rather than a documented expectation, because the latter is not a control.
Where it sits with single sign-on
If authentication is federated, the second factor is enforced at the identity provider and the document system inherits it. That is the right place for it — but confirm it is actually enforced there rather than assuming, because an unenforced identity provider policy protects nothing.
FAQ
Two-factor authentication: common questions
Should we require 2FA for every user?
For anyone who can approve, administer or export, yes. For occasional read-only users it is a judgement about friction against risk, and the answer depends on how sensitive the repository is.
What about shared or service accounts?
Shared accounts should not exist in a document system — they defeat attribution, which is the foundation of every audit control. Service accounts should use scoped API keys rather than user credentials.
Related terms
- Access reviewAn access review is a periodic check that the people who have access to something still need it.
- API keyAn API key authenticates a program rather than a person.
- Break-glass accessBreak-glass access is a deliberate, time-boxed grant of permissions a user does not normally hold, for genuine emergencies.
- Data residencyData residency is the commitment that data is stored and processed within a specified country or region.
- Encryption at restEncryption at rest protects stored data by encrypting it on disk, so that physical access to the storage medium does not yield readable content.
- Permission inheritancePermission inheritance means a document takes its access rights from the folder containing it, rather than being permissioned individually.
Última revisão: 28 de agosto de 2026. Browse the full glossary.