Two-Factor Authentication for Your ATS: Protecting Sensitive Candidate Data from Breach

Why ATS security requires the same rigour as financial systems

When organisations think about systems that require robust security controls, they typically think first of financial systems — banking platforms, payment processors, payroll software. The reasoning is straightforward: financial systems hold monetary value, and a breach creates direct, quantifiable losses. What is less commonly recognised is that an ATS presents a security risk profile that is comparable in severity and arguably more complex in its consequences.

An ATS contains personally identifiable information — PII — for every person who has ever applied to your organisation. Depending on the scale and longevity of your recruitment operation, that might be tens of thousands or hundreds of thousands of individual records. Each record typically includes: full name, email address, phone number, home address, employment history, educational background, salary expectations or history, and often copies of identity documents, CV files and covering letters. For candidates who progressed to offer stage, the records may also include bank details for payroll onboarding.

A breach of this data is not an abstract compliance problem. It is a concrete harm to real people: candidates whose personal information is exposed to identity theft, financial fraud, unwanted contact and other downstream harms. It creates immediate legal obligations for your organisation under GDPR: breach notification to your supervisory authority within 72 hours, notification to affected data subjects if there is high risk to their rights and freedoms, and documentation of the breach and your response. It carries reputational damage that affects both recruitment brand (candidates choose not to apply) and general brand (customers and partners lose trust).

The mechanisms by which ATS data is breached are not exotic. The vast majority of breaches in cloud software begin with compromised credentials — a username and password obtained through phishing, purchased from a data breach marketplace, or successfully guessed. Two-factor authentication addresses this directly: even when credentials are compromised, the attacker cannot access the account without the second factor. It is the most effective, most deployable access control measure available for protecting ATS data.

What 2FA prevents: credential theft and account takeover

Two-factor authentication prevents account takeover in scenarios where an attacker has obtained valid credentials — meaning a working username and password combination. Understanding the common ways credentials are obtained helps make clear why 2FA is necessary rather than merely cautious.

Phishing is the most prevalent credential theft method. An employee receives an email that appears to be from a legitimate service — LinkedIn, Google, a bank — asking them to log in through a link. The link leads to a convincing replica of the login page. The employee enters their credentials and the attacker captures them. Phishing attacks have become highly sophisticated; even security-aware employees are successfully phished. If the ATS uses the same password as the account targeted in the phishing attack, or if the phishing site impersonates the ATS itself, the attacker can log into the ATS with the captured credentials.

Credential stuffing is a different attack vector that requires no targeting of your organisation specifically. Billions of username-password pairs from historical data breaches are available for purchase on criminal marketplaces. Automated tools test these combinations against the login pages of common software services. If any of your ATS users have reused a password from a previously breached account, credential stuffing will find it. Password reuse is extraordinarily common despite repeated warnings about it — organisations cannot rely on employees to maintain unique passwords for every service they use.

Both attack vectors are completely neutralised by 2FA. An attacker with a valid username and password cannot access the account without the time-sensitive code from the user's authenticator app or SMS. The stolen credential has zero value against a 2FA-protected account. This is why 2FA adoption is the single most impactful security measure an organisation can implement for cloud software access.

2FA methods compared: authenticator app, SMS, hardware keys

Not all 2FA methods offer the same level of security. Understanding the distinctions allows organisations to make informed decisions about which method to require, and whether different user roles or risk levels should require different methods.

Authenticator app (TOTP — Time-based One-Time Password) is the recommended standard for ATS access. The authenticator app (Google Authenticator, Authy, Microsoft Authenticator, or any TOTP-compatible app) generates a six-digit code that changes every 30 seconds based on a shared secret established at setup. The code is generated locally on the device and never transmitted until the user enters it during login. An attacker cannot intercept the code in transit, cannot generate future codes, and cannot replay a used code. The only way to defeat TOTP is to physically access the user's device or to conduct a real-time phishing attack that captures the TOTP code in the same session it is generated — a considerably more difficult attack than standard credential theft.

SMS verification sends a one-time code to the user's registered phone number. SMS 2FA is significantly more secure than no 2FA — it still requires the attacker to control the user's phone number, not just their password. However, SMS has known vulnerabilities: SIM swap attacks (where an attacker social engineers a mobile carrier into transferring a victim's number to an attacker-controlled SIM) and SS7 protocol weaknesses (that can allow interception of SMS messages at the network level) make SMS a less robust second factor than authenticator app. For most HR teams, SMS is an acceptable option for lower-risk user roles or as a fallback for users who cannot install authenticator apps.

Hardware security keys (FIDO2/WebAuthn), such as YubiKey, provide the strongest available 2FA. They are phishing-resistant by design — the key cryptographically verifies the domain of the site requesting authentication, preventing phishing sites from obtaining a valid authentication even if the user is tricked into visiting one. For security-critical roles with access to the complete candidate database, hardware keys represent best practice. For most ATS deployments, the combination of TOTP authenticator app plus enforcement across all users provides an appropriate and practical level of security.

Rolling out 2FA to your team: implementation approach

The technical capability to enable 2FA is only part of the implementation challenge. Organisational rollout — getting all users enrolled and accustomed to the additional login step — requires a deliberate change management approach. The two most common rollout failures are: forcing immediate enforcement that locks confused users out at an inconvenient moment, and announcing 2FA as mandatory but never actually enforcing it, resulting in persistent non-adoption.

The recommended approach is a phased rollout. In phase one (advisory, lasting two to four weeks), 2FA is enabled as an option in the ATS settings. A communication is sent to all users explaining what 2FA is, why it is being implemented, how to set it up (step-by-step instructions with screenshots), and the date on which it will become mandatory. Users who set up 2FA voluntarily during this period experience no disruption at enforcement — the transition for them is transparent. Weekly reminders during the advisory period, showing how many users have enrolled and how many have not, create gentle social pressure toward adoption.

In phase two (mandatory enforcement), all users who have not yet enrolled are prompted to set up 2FA at their next login before they can access the system. They are not locked out — they can complete the setup immediately — but they cannot bypass it. The setup process should take less than three minutes for most users. Providing a support resource (documented setup guide, brief video walkthrough, or a helpdesk contact) reduces friction for the small number of users who encounter difficulties.

After enforcement, the administrator dashboard should show 2FA status for all users, allowing the IT or HR operations team to confirm that no active accounts remain without 2FA enrolled. Accounts that were inactive before enforcement (former employees whose access was not revoked) should be audited and deactivated — a secondary security benefit of the rollout process.

2FA for external users: hiring managers and agency recruiters

Most ATS deployments include users who are not internal employees: hiring managers from client organisations (in agency contexts), external agency recruiters with limited pipeline access, or departmental hiring managers in organisations where the recruiter grants access to the relevant manager for each search. These external users present a specific security challenge that internal user management does not address.

External users typically have less security awareness training than internal staff, use personal devices that are not subject to organisational security policies, and may use the ATS infrequently enough that they are more likely to forget their password (and therefore more likely to create weak or reused passwords when forced to reset). They are also potentially less motivated to comply with security requirements if compliance creates friction for them.

Despite these challenges, external users with ATS access have the same ability to view candidate PII as internal users — making them part of the same security risk profile. The appropriate approach is to enforce 2FA for all user roles, including external ones, with role-based configuration for the specific data access granted. A hiring manager with read-only access to a single pipeline does not need the same access level as a recruiter with full candidate database access, but both should authenticate with 2FA.

For agency recruiter accounts — where the same individual may access multiple client ATS instances — the authenticator app approach is preferable to SMS, since the authenticator app can hold multiple accounts without requiring separate phone numbers. This makes the authentication experience more consistent for users who log into multiple systems regularly.

GDPR Article 32 and security obligations for HR data

GDPR Article 32 places a direct legal obligation on data controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. For organisations processing personal data at scale in an ATS, this is not a vague aspirational standard — it has practical implications for what technical controls must be in place.

The Article 32 assessment considers the nature, scope, context and purposes of processing, as well as the likelihood and severity of risks to individuals. An ATS scores high on all of these dimensions: the personal data is detailed and sensitive (employment history, financial information, identity details), the scale is significant (potentially thousands or hundreds of thousands of candidates), the context is professional (candidates have a reasonable expectation that their data is securely managed), and the risks of unauthorised access are concrete (identity theft, financial fraud, professional harm).

Given this risk profile, appropriate technical measures for an ATS include: data encryption at rest and in transit (standard in cloud ATS platforms), access controls with role-based permissions (limiting who can see what data), audit logging of access events, and strong authentication mechanisms. Two-factor authentication falls squarely within the category of strong authentication mechanisms that Article 32 points toward for systems processing personal data at significant scale.

Data protection authorities across the EU have increasingly cited inadequate access controls — including absence of MFA — as contributing factors in breach investigations and enforcement actions. While GDPR does not mandate specific technical implementations by name, DPA guidance and enforcement patterns make clear that relying on password-only authentication for a system containing large volumes of personal data is likely to be assessed as insufficient under Article 32's proportionality requirement.

Balancing security and user experience

The most common objection to 2FA in HR teams is the user experience impact: it adds a step to every login, requires users to have their phone available, and creates friction for users who log in many times per day. These concerns are legitimate but manageable with thoughtful configuration.

Most ATS 2FA implementations allow configuring a "remember this device" period — typically 7 to 30 days — during which a verified device does not prompt for a second factor on subsequent logins. A recruiter who logs in from the same laptop every day will be prompted for their 2FA code once, and then not again for the configured period. The daily login experience for most users is unchanged; only the first login on a new or unrecognised device requires the second factor.

For users who access the ATS from multiple devices — a laptop at the office, a different laptop at home, occasionally a tablet — the trusted device period means they experience 2FA occasionally but not constantly. The friction is proportionate to the actual security value being delivered: the highest-friction moment (first login on an unrecognised device) is also the highest-risk moment (a device the system has not verified before).

Communicating the security rationale clearly also reduces resistance. Users who understand that 2FA protects candidate data — and that the organisation has a legal obligation to protect that data — are generally more accepting of the additional login step than users who receive it as an unexplained policy change. Frame the rollout around data protection responsibility, not around organisational IT policy, and adoption resistance is typically lower.

Frequently asked questions about 2FA for ATS security

Why does an ATS need two-factor authentication?

An ATS contains detailed personally identifiable information (PII) for every candidate who has ever applied to your organisation — names, contact details, employment history, salary expectations and in many cases sensitive documents such as ID copies or proof of right to work. This makes it a high-value target for credential theft and account takeover attacks. Two-factor authentication ensures that even if a user's password is compromised through phishing, data breach reuse or guessing, the attacker cannot access the ATS without also controlling the user's second factor. It is the single most effective technical control for preventing unauthorised account access.

Which 2FA method is most secure for ATS access?

Authenticator app (TOTP — Time-based One-Time Password) is the most secure 2FA method commonly available in ATS software. It generates a six-digit code that changes every 30 seconds and is not transmitted over the network until the user enters it. SMS verification is less secure because SIM-swap attacks and SS7 protocol vulnerabilities can allow attackers to intercept SMS codes — though SMS 2FA is still significantly better than no 2FA at all. Hardware security keys (FIDO2/WebAuthn) are the most secure option but are impractical for most HR team deployments. For most organisations, authenticator app TOTP provides the right balance of security and usability.

Does enabling 2FA comply with GDPR Article 32 requirements?

GDPR Article 32 requires organisations to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. For systems containing significant volumes of personal data — such as an ATS — appropriate technical measures include access controls, encryption and authentication. Two-factor authentication is widely recognised as an appropriate and proportionate access control measure for systems containing personal data at scale. While GDPR does not explicitly mandate 2FA by name, implementing it is directly relevant to demonstrating compliance with Article 32's security obligations.

How should 2FA be rolled out to an existing ATS user base?

Roll out 2FA in two phases. In the first phase (advisory), enable 2FA as an option and communicate to all users that it will become mandatory within 30 days, including instructions for setting it up. Users who enrol voluntarily during this period experience no disruption when enforcement begins. In the second phase (mandatory enforcement), require 2FA at login for all users who have not yet enrolled. Users who have not set it up are prompted to do so before accessing the system. This phased approach avoids locking users out unexpectedly while ensuring universal adoption within a defined timeframe.