Agentless MFA for Active Directory: How DSPA Works
Quick answer: Agentless MFA for Active Directory means adding a second authentication factor at the directory level itself, rather than installing a client-side agent on every endpoint or configuring a separate integration for every AD-connected service. Protectimus DSPA (Dynamic Strong Password Authentication) implements this by replacing a user’s AD password with a rotating dynamic time-based one-time password. Because the change happens inside Active Directory, any service that authenticates directly against the AD password (Winlogon, RDP, LDAP-bound applications, command-line AD access) inherits the protection automatically. For setup instructions, see the DSPA integration guide. For help deciding whether an agentless or component-level approach fits your environment, see MFA for Active Directory: Complete Guide.
Table of Contents
- What «Agentless» Means for Active Directory MFA
- How DSPA Achieves Directory-Level Coverage
- Requirements & Limitations
- What Services Get Protected Automatically
- Agentless vs. Component-Level: A Closer Look
- Where TOTP Fits Alongside FIDO2 and Passkeys
- Security Implications: MFA Bypass, Credential Theft, and Lateral Movement
- FAQ
- Conclusion
Key facts
Credential replay has a shelf life
By continuously rotating AD passwords, DSPA limits the window for reusing stolen passwords, potentially to just seconds, depending on when the credentials are captured and the rotation interval an administrator sets.
One integration, several entry points
Winlogon, RDP, LDAP-bound applications, and command-line AD access all check the same Active Directory password. That’s exactly the layer DSPA operates on.
Rotation in 30-second steps
Administrators set the password rotation interval in multiples of 30 seconds, and the user’s authenticator app or chatbot generates codes on the same schedule.
What "Agentless" Means for
Active Directory MFA
«Agentless» gets used loosely across the MFA industry, so it’s worth being precise about what it means specifically for Active Directory.
Most MFA vendors install a small piece of software (an agent) on the machine or server where authentication happens: a Windows login screen, an RDP gateway, a VPN concentrator, a webmail login page. The agent sits in front of that login process, intercepts the attempt, and prompts for a second factor before letting the user through. This works well and is the more common model across the industry, but it means each protected entry point needs its own agent, its own configuration, and its own maintenance schedule.
Agentless, directory-level MFA takes a different route. Instead of intercepting authentication at each individual endpoint, it changes what counts as a valid credential inside the directory itself. Protectimus DSPA does this by continuously updating users’ passwords directly in Active Directory with dynamic time-based one-time passwords (TOTP). Passwords are automatically rotated at administrator-defined intervals, which must be multiples of 30 seconds.
Nothing is installed on user workstations or on the servers running AD-connected applications. The directory enforces the check because the password itself is now time-limited: any system that was already built to validate a password against Active Directory continues doing exactly that, just against a password that no longer stays the same.
This distinction matters for how you scope a rollout. Component-level MFA answers the question «does this specific service require a second factor?» one service at a time. Directory-level MFA answers a different question («what counts as a valid AD password?») once, at the source.
How DSPA Achieves Directory-Level Coverage
The mechanics of DSPA’s password rotation (how the OTP is generated, how the rotation interval is configured, how it connects to Active Directory via LDAP/LDAPS) are covered in detail in the DSPA integration guide. This section focuses on a different question: why does this mechanism produce broad coverage without per-service configuration?
A conventional MFA agent has to be told, explicitly, which service it’s protecting. A Winlogon agent knows about Winlogon. An OWA plugin knows about OWA. Neither is aware the other exists, and neither one does anything for a service it wasn’t built to protect. Every new AD-connected application, in this model, means evaluating whether a matching integration exists, and building one if it doesn’t.
DSPA sidesteps this by operating one layer down, at the point where every one of those services already asks the same question: does this password match what’s stored in the directory? Once DSPA controls that answer, rotating the dynamic time-based one-time password on the administrator’s schedule, every service asking the question gets the updated answer automatically. Nothing about Winlogon, RDP, OWA, or an LDAP-bound application individually needs to change. They were already built to check the AD password; that’s precisely the mechanism DSPA modifies.
Generates dynamic TOTP passwords and manages rotation
▼
User password = current dynamic OTP
Automatically updated at administrator-defined intervals
▼
Windows Logon / RDP
OWA / ADFS
LDAP Applications / Command-Line Access
VPN / Wi-Fi (when authentication relies on AD)
No separate MFA integration required for each service
This is also why DSPA reaches entry points that per-service agents typically miss. Direct LDAP queries and Windows command-line AD access don’t go through a login screen an agent could intercept: there’s no UI to sit in front of. But they do check the same AD password DSPA controls, so the same rotation applies there without any additional configuration.
The trade-off is that DSPA’s effect is broad by design. It isn’t possible to enable DSPA for one service and leave another one unaffected within the same directory scope: coverage follows the password, not the application. Administrators do have finer control through group-based policy: DSPA can be scoped to specific AD security groups, so it’s possible to roll it out to privileged accounts first, or to leave certain user groups on standard authentication during a transition period. What isn’t possible is applying it to one service while excluding another for users who are otherwise in scope.
Requirements & Limitations
Deployment Requirements
Protectimus DSPA is deployed alongside the Protectimus On-Premise MFA Platform, either on your own servers or in a private cloud, and isn’t available through the Protectimus Cloud Service. Hardware and software requirements for both options are listed on the Protectimus DSPA product page.
Coverage & Limitations
DSPA supports group-based policies, allowing administrators to enable password rotation for selected AD security groups. Protection applies to services that validate credentials against the current Active Directory password. VPNs and Wi-Fi may require additional configuration to connect their authentication to AD, often through RADIUS.
Because DSPA operates at the directory level, it cannot be enabled for one application while excluded from another for the same protected user.
Service Accounts and Stored Credentials
DSPA replaces static AD passwords with rotating OTPs. As a result, applications, services, scheduled tasks, or scripts that rely on stored static passwords will no longer be able to authenticate if their accounts are protected by DSPA. Administrators should review these dependencies before enabling password rotation and exclude accounts that must continue using static passwords from DSPA-enabled security groups.
What Active Directory Services Can DSPA Protect
Once DSPA is integrated with Active Directory, the rotating OTP requirement applies to every service that authenticates directly against the AD password, without a separate endpoint agent or per-service integration.
Windows Authentication
- Winlogon: domain-joined workstation login
- RDP (Remote Desktop Protocol): remote access to Windows servers and workstations
- Windows Server authentication: server-level access
Microsoft Email and Collaboration
- OWA (Outlook Web Access): webmail access via Active Directory authentication
- Exchange ActiveSync: mobile email synchronization
Directory Services
- LDAP authentication: any application querying AD directly
- Command-line AD access: programmatic access via Windows command line or scripts
Federation Services
- ADFS 3.0 and 4.0: federated authentication inherits DSPA-protected credentials, since AD FS relies on Active Directory for the underlying password check
What about VPNs and RADIUS-based authentication?
DSPA protection also extends to VPNs and other services that validate user passwords against Active Directory, including those connected through RADIUS. RADIUS is one of the ways to connect a VPN to Active Directory for user authentication. The Protectimus RADIUS component provides an option for integrating VPNs and other RADIUS-compatible systems with Active Directory and Protectimus MFA.
Comparison of coverage
| Service | Component-level MFA | Directory-level MFA (DSPA) |
|---|---|---|
| Winlogon | Requires a dedicated agent | Covered automatically |
| RDP | Requires a dedicated agent | Covered automatically |
| OWA | Requires a dedicated plugin | Covered automatically |
| LDAP-bound applications | Not covered by endpoint agents | Covered automatically |
| Command-line AD access | Not covered by endpoint agents | Covered automatically |
| ADFS-federated apps | Requires a dedicated component | Inherits protection via AD FS |
| RADIUS-connected services (VPN, Wi-Fi) | Covered via the RADIUS component | Covered automatically when authentication relies on AD password validation |
The practical implication of the last row is worth emphasizing: while services like Windows Logon and OWA already rely on Active Directory for authentication, others, such as VPNs and Wi-Fi, may require additional configuration to connect to AD. RADIUS is one of the ways to establish this connection. Once these services authenticate directly against the AD password, they automatically benefit from DSPA protection, without requiring a separate MFA integration for each service.
Agentless vs. Component-Level MFA: What's the Difference
The practical difference between the two approaches shows up most clearly in three places: what happens when a new AD-connected service is added, what happens during an outage, and what an attacker sees when probing the environment.
Adding a new service. With component-level MFA, a new AD-connected application means evaluating whether a matching MFA integration exists, and building one if it doesn’t, which can leave a gap between when a service goes live and when it’s actually protected. With DSPA, a new service that authenticates against the AD password is covered the moment it’s connected to the directory, with no additional integration step required.
Failure behavior. A component-level agent that fails open, is misconfigured, or gets bypassed leaves exactly one service unprotected while the rest of the environment is unaffected: a contained failure. A DSPA outage, on the other hand, can affect authentication across multiple services that rely on DSPA-protected AD credentials. This is why DSPA deployments benefit from the same clustered, high-availability infrastructure as the rest of the Protectimus On-Premise Platform (recommended minimum is 3-node clustering with automatic failover) rather than running as a standalone service.
What an attacker sees. Component-level MFA protects the services it’s configured for and nothing else. An attacker who finds an AD-connected path without a matching agent (a direct LDAP query, a legacy application, a script using stored credentials) can often authenticate without hitting an MFA prompt at all, simply because no agent was watching that path. Because DSPA controls the password itself rather than a specific login screen, that kind of gap closes by default for services that rely on AD password authentication, rather than requiring each entry point to be identified and covered one integration at a time.
None of this makes directory-level MFA categorically superior. Component-level MFA remains the better fit when the goal is to protect one or two specific entry points without changing authentication anywhere else, or when different systems have different rollout owners and timelines. The architectural differences above are what should inform that choice, not a general claim that one approach is «more secure.»
Where TOTP Fits Alongside FIDO2 and Passkeys
A reasonable question in 2026 is how TOTP-based MFA for Active Directory relates to newer phishing-resistant methods like FIDO2, WebAuthn, and passkeys.
The practical answer: on-premise Active Directory environments, especially legacy services like Winlogon, RDP, LDAP, and command-line AD access, do not natively support FIDO2 across all entry points. TOTP-based MFA via DSPA closes those gaps today, working uniformly across every AD-authenticated service that checks the directory password directly, including legacy systems that lack native FIDO2 support.
Organizations can deploy DSPA for broad AD coverage while using FIDO2 for high-value cloud applications accessed via ADFS or a cloud identity provider. The two approaches are complementary rather than competing: FIDO2 provides phishing-resistant authentication for the entry points that support it, while DSPA reduces phishing-related credential theft risks by replacing permanent AD passwords with rotating OTPs and extends protection to the on-premise entry points that lack native FIDO2 support.
Security Implications: MFA Bypass, Credential Theft, and Lateral Movement
Traditional client-based MFA protects specific authentication points, such as Windows Logon, RDP, or VPN access, but may leave alternative paths to Active Directory unprotected. An attacker with stolen credentials could bypass these MFA checks by authenticating through Windows command-line tools, LDAP-connected applications, or another service without its own MFA integration.
Credential theft through phishing, malware, or techniques such as DCSync creates opportunities for credential replay and password-based lateral movement. Because DSPA continuously rotates user passwords directly in Active Directory, stolen passwords have a much shorter window of usefulness. An attacker who captures a password one second into a 30-second rotation interval may have as little as 29 seconds to use it before the password changes.
Unlike endpoint-specific MFA, DSPA protects the AD password itself. Every service that validates credentials against the current AD password requires the current dynamic OTP, regardless of where the authentication request originates. This reduces opportunities to bypass MFA through alternative entry points and reuse stolen passwords across the infrastructure, without deploying a separate MFA component for each service.
FAQ
Can MFA be applied to specific Active Directory groups rather than all users under DSPA?
Yes. DSPA supports group-based MFA policy: administrators can apply directory-level password rotation only to specific AD security groups, which is useful for phased rollouts, starting with IT administrators and privileged accounts before extending coverage further. Users outside the protected group continue authenticating with their standard static password until they’re added to the group.
What happens if a user loses access to their authenticator app under DSPA specifically?
Because the AD password itself depends on the current OTP, losing access to the authenticator blocks login until it’s resolved, not just to one application but to every AD-connected service at once. Protectimus SMART supports cloud backup, so users can restore their token to a new device without administrator intervention. For other cases, an administrator can temporarily exempt the affected user from DSPA rotation via the admin console while a new token is issued.
How does DSPA compare to FIDO2 keys and passkeys for Active Directory?
FIDO2 and passkeys are phishing-resistant and work well for ADFS-federated applications and cloud scenarios, but they have limited native support across legacy on-premise AD entry points such as Winlogon, RDP, and LDAP. DSPA covers those entry points uniformly with TOTP-based rotation. The two approaches are commonly deployed together rather than treated as alternatives.
Does DSPA cover VPN and Wi-Fi access?
Yes, provided their authentication relies on Active Directory password validation. VPN and Wi-Fi may require additional configuration to connect to AD, often through RADIUS. Once authentication relies on the AD password, these services automatically benefit from DSPA’s password rotation without requiring a separate MFA integration.
Conclusion
Agentless, directory-level MFA solves a specific problem: covering every service that authenticates against Active Directory without building and maintaining a separate integration for each one. Protectimus DSPA does this by rotating the AD password itself rather than intercepting logins at each endpoint, which is also why it reaches entry points, such as direct LDAP and command-line access, that endpoint-based MFA typically doesn’t.
It isn’t a universal replacement for component-level MFA. Organizations already relying on FIDO2 for cloud applications will likely keep doing so for those entry points. The value of the directory-level approach is concentrated where component-level MFA structurally struggles: broad, uniform coverage across everything that relies on AD password validation, including access paths such as LDAP authentication and command-line tools that don’t necessarily present a login screen for an agent to protect in the first place.
For setup instructions, see the DSPA integration guide. If you’re still deciding whether an agentless or component-level approach fits your environment, see MFA for Active Directory: Complete Guide.
