Reference Glossary
Two-factor authentication
A DAM login requirement combining a password with a second factor — a one-time code, authenticator app, or hardware key — before granting access to the asset library.
Why it matters in a DAM
DAM libraries often hold unreleased campaign creative, embargoed product photography, and personal data subject to GDPR or HIPAA, so a single compromised password from phishing or credential reuse can expose the entire library in one step; two-factor authentication blocks that account takeover even after the password itself has leaked, because the attacker still needs the second factor. It's a small control that closes off the most common real-world entry point — stolen or reused credentials — rather than a defense against a sophisticated targeted attack specifically.
A worked example
Common mistake
Enforcing two-factor authentication for internal employee accounts but exempting external contributors, agency, or guest accounts "because it's inconvenient for occasional users" — leaving the least-monitored, most loosely managed accounts as the easiest way into the library.
Two-factor authentication requires a second, independent proof of identity beyond a password — typically a time-limited code from an authenticator app, a text message, or a hardware security key — before a DAM login succeeds. It’s a standard control across enterprise software generally, but it carries particular weight for a DAM specifically because of what a compromised login exposes: not a single record or transaction, but potentially the entire asset library, including unreleased campaign work and embargoed product imagery whose value depends on staying unseen until launch.
The threat model two-factor authentication actually defends against is the mundane one, not a sophisticated targeted attack: password reuse across services, phishing pages that harvest credentials, and credential-stuffing attempts using passwords leaked from unrelated breaches. All of these hand an attacker a valid password without any effort spent on the DAM itself, and a second factor stops the login there even though the password worked.
The common shortfall is applying it unevenly. Internal staff accounts get 2FA enforced through single sign-on, while external contributor, freelancer, or agency guest accounts — set up quickly for a single project and rarely revisited — are left on password-only login because enforcing 2FA for occasional external users feels like friction not worth adding. Those accounts are exactly the ones least likely to be monitored for suspicious activity, which makes skipping 2FA on them the opposite of where the risk actually sits.
Frequently asked
Why does 2FA matter more for a DAM than for some other systems?
A DAM is a centralized repository, not a single-record system — one login can grant broad, sometimes admin-level, access across folders: brand campaigns, product photography, embargoed releases, and GDPR- or HIPAA-regulated files. Where a compromised CRM account typically exposes one contact or transaction, a password-only DAM account can expose the entire library in a single breach, including unreleased creative and regulated data across every project the account touches.
What threat does 2FA actually defend against?
2FA mainly defends against everyday credential compromise, not exotic exploits: password reuse across services, so a password leaked in an unrelated breach still works on the DAM; credential-stuffing bots that test large batches of breached username/password pairs against login pages; and phishing pages that trick users into typing their password directly into a fake login form. These are common, low-skill attack paths — 2FA closes all three by requiring a second factor the attacker doesn't have.
Does 2FA stop an attacker who already has a valid password?
Yes — with a valid password alone, an attacker still needs the second factor to finish logging in: a rotating code from an authenticator app, a push approval on the registered device, or a hardware key. The main exception is real-time phishing relay, where an attacker-in-the-middle page forwards the password and prompts for the one-time code as the victim types it — a risk that SMS and TOTP carry but hardware security keys resist, since they cryptographically bind to the genuine site.
What's the common mistake organizations make when rolling out 2FA?
Two patterns recur. First, treating 2FA as a policy for full-time staff enrolled via SSO or directory sync, while exempting external contributors, agencies, or guest accounts as "too inconvenient to onboard" — leaving the least-monitored accounts as the only password-only entry point. Second, offering SMS as the sole second factor rather than an authenticator app or hardware key, which leaves the rollout vulnerable to SIM-swap attacks even after 2FA is technically "enabled" everywhere.
What forms can the second factor take?
An authenticator app generates a time-based one-time code (TOTP) that rotates every 30 seconds; a text message delivers a one-time code over SMS — the most widely supported option, but weaker since phone numbers can be SIM-swapped; a push notification sends an approval prompt to the user's registered device to tap and confirm; and a hardware security key, plugged in via USB or tapped over NFC, uses public-key cryptography bound to the actual site, the most phishing-resistant choice.
Why are external guest accounts a bigger 2FA risk than internal ones?
External guest and contributor accounts are typically created ad hoc for a single project or campaign, sometimes shared across an agency team, and often left active after the project wraps because no one owns deprovisioning them. They fall outside the regular access-review cycle applied to staff accounts, so unusual login activity goes unnoticed longer. Combined with password-only access, that low oversight makes guest accounts the easiest entry point for credential-stuffing or phishing attacks aimed at the DAM library.