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 compromised login can expose the entire asset library at once — including unreleased campaign creative and embargoed product imagery — not just a single record or transaction.
What threat does 2FA actually defend against?
The mundane, common one — password reuse across services, phishing, and credential-stuffing from unrelated breaches — not primarily a sophisticated targeted attack.
Does 2FA stop an attacker who already has a valid password?
Yes — 2FA blocks account takeover even after the password itself has leaked, because the attacker still needs the second factor to complete login.
What's the common mistake organizations make when rolling out 2FA?
Enforcing it for internal employee accounts through SSO but exempting external contributor, agency, or guest accounts as "too inconvenient" — leaving the least-monitored accounts as the easiest way in.
What forms can the second factor take?
A time-limited code from an authenticator app, a text message, or a hardware security key, in addition to the password.
Why are external guest accounts a bigger 2FA risk than internal ones?
They're set up quickly for a single project and rarely revisited, making them the accounts least likely to be monitored for suspicious activity if left on password-only login.