# Relocate the Control When the User Won't Adopt It ## Claim When a security control depends on cooperation a user won't reliably give, moving enforcement to a layer that user doesn't participate in converts an unwinnable persuasion problem into an architecture decision the operator can actually control. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies wherever the binding constraint on a security measure is client or user resistance rather than the absence of a technical solution — password managers and 2FA both exist and work; the gap is adoption, not availability. - Strongest where a layer genuinely sits outside the resistant party's normal path — a gateway or proxy in front of a login page the user never has to configure or opt into. - Does not eliminate the underlying risk the resistant behavior created; it removes the dependency on that behavior changing. The user who won't adopt 2FA is still not using 2FA — the exposure is closed a different way. - Breaks down where the authorized user who resisted the original control also holds the access needed to disable the relocated one — an admin who wouldn't turn on 2FA can often still turn off a security plugin or reconfigure a proxy setting, which is why protecting the relocated control's own configuration is a distinct, additional problem this move does not solve by itself. - Generalizes past WordPress security to any compliance or safety problem where the resistant party is a person rather than a system: relocating the control to infrastructure they don't touch is the general move, described here in its login-security instance. ## Evidence > [!quote] ID:rw_tab_2fa_zerotrust > Cloudflare ZeroTrust in front of the login pages. So far it's been fantastic. From a WordPress agency discussion on login protection: Paul Thompson opens the thread by naming the actual binding constraint — "PW managers are still problematic/unintuitive for less tech-inclined site owners, unfortunately, and they resist or stop using them" — which relocates the whole problem from tool selection to client behavior. Dan Lockcuff's Cloudflare Zero Trust answer, quoted above, is the architectural response specifically aimed at clients who won't cooperate with 2FA: it sits in front of the login page at a layer the client never has to touch, cooperate with, or even know is there. ## Links - [[3. Resources/Permanent Notes/Vendor Content Establishes a Standard and Then Exempts Itself From It]] — a structural parallel worth flagging rather than treating as equivalent: Common Room's visitor-identification pitch also moves the point of contact to a layer the original party (the site visitor, rather than the resistant user here) doesn't participate in — one relocation closes a security gap the resistant party created, the other bypasses the consent a visitor would otherwise have to give, and the same architectural move serves opposite ends depending on who benefits from the party's non-participation - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — home for the vault's WordPress-specific security-architecture claims, of which this relocate-the-control pattern is a recurring instance ## Tests / falsifiers - Find a documented case where a relocated control (gateway, proxy, WAF rule) was itself disabled by the same authorized user whose non-cooperation prompted the relocation — a real instance would confirm the scope condition above and argue for pairing this move with a second control that protects the relocated control's own configuration from that same user. - Compare incident rates before and after a Zero-Trust-style relocation at agencies managing many low-cooperation clients — if incidents don't measurably drop, the claim that relocation "converts an unwinnable persuasion problem into an architecture decision" would need to be narrowed to "removes the dependency" without implying the underlying risk is actually closed. ## Source - [[3. Resources/Readwise/Articles/Best Login Protection & 2FA for WordPress Agencies - The Admin Bar]] — an agency discussion thread naming client resistance as the binding constraint, with distinct proposed answers (Cloudflare Zero Trust, Shield Security's Security Admin config-protection feature, and Wordfence-plus-triage). This note covers only the relocation move; the config-protection and detection-needs-a-responder threads in the same source are separate claims worth their own treatment if this doc is revisited.