Acta AI
March 30, 2026
WordPress sites face roughly 65 million brute-force login attempts every day (SQ Magazine, 2025). Most of those attacks target one thing: your main admin password. The moment you hand that credential to a third-party tool, a plugin, or an automation service, you've made yourself a much easier target.
App passwords solve this cleanly. They give external tools a separate, revocable key that works only through the REST API, so your real login stays protected. In this guide, I'll walk through exactly what app passwords are, how to create one in under five minutes, what can go wrong, and how to clean up old ones before they become a liability.
TL;DR: WordPress app passwords are unique, revocable credentials that let external tools access your site via the REST API without exposing your main login. As of 2025, creating and managing them correctly is one of the fastest security wins available to any WordPress site owner. You can set one up in under five minutes from your existing dashboard, no plugins required.
A WordPress app password is a separate, auto-generated credential that lets a specific external application, like a publishing tool, REST API client, or autoblogger, connect to your site without using your real admin password. Built into WordPress core since version 5.6, it can be revoked any time without changing your main login or disrupting other integrations.
Your main password authenticates you as a human in a browser. An app password authenticates a machine or service through the REST API. These are fundamentally different access pathways, and keeping them separate is the whole point.
The security benefit is immediate. If an app password leaks, you revoke it in seconds. Your admin account stays intact: no forced credential reset, no audit spiral, no locked-out integrations. Contrast that with sharing your real password, where a single breach forces you to change your login everywhere it's been used, then figure out what accessed what and when.
I saw this problem up close when building publishing integrations for consulting clients. The first version of my Python script required clients to paste a live admin password directly into a config file. The discomfort of that moment was real. A client's config file sitting on a shared desktop, containing full admin access to their WordPress store, is not a security posture. It's a liability. That experience drove the entire authentication rethink, and app passwords became the standard from that point forward.
No plugin required. App passwords have been built into WordPress core since version 5.6, released in December 2020. You access them directly from any user profile page inside your WordPress dashboard, with no additional software to install.
Creating a WordPress app password takes under five minutes. You go to Users, open the profile of the account you want to connect, scroll to the Application Passwords section, type a label for the app, click "Add New Application Password," and copy the generated string immediately. WordPress will never show it again.
Here's the exact sequence:
Verify your output: Paste the credential into your publishing tool's authentication field alongside your WordPress username and site URL. If the connection test passes, you're done.
The credential WordPress generates is a 24-character string broken into groups with spaces. When pasting it into a tool or script, leave the spaces in. WordPress strips them automatically during authentication, so removing them manually wastes time and risks a typo.
Here's the friction point I see most often when walking non-technical clients through this on a screen share: they spend the first two minutes hunting for a "Generate Password" button near the top of the profile page, right next to the regular password field. The Application Passwords section lives much further down. I added a note about the scroll distance to my onboarding checklist after the first time it caused confusion, and it's been there ever since.
Only 34% of WordPress admin accounts globally have two-factor authentication enabled (SQ Magazine, 2025). Even without 2FA, scoped credentials like app passwords cut your exposure significantly, because a compromised app password can only reach the REST API, not your full admin dashboard.
Use the name of the specific tool or integration you're connecting, not something generic. A label like "Acta AI, Blog Publisher" or "Zapier, Post Creator" tells you exactly what to revoke if something goes wrong. Vague labels become a security guessing game six months later when you're staring at a list of five passwords named "API Key" and "Test2."
App passwords are significantly safer than sharing your main admin credential, but they are not a complete security solution on their own. They protect your login from exposure, but the app password itself is still a credential that can be stolen if transmitted without encryption or stored carelessly in a spreadsheet or plain-text config file.
The genuine benefits are concrete: app passwords are scoped to REST API access only, they can be revoked individually without touching other integrations, and they don't grant dashboard login access by themselves. That last point matters. Even if someone intercepts an app password, they cannot log into your WordPress admin panel with it directly.
The catch is that app passwords are disabled by default on some managed WordPress hosting environments. Certain configurations of WordPress.com, WP Engine, and Kinsta block the feature outright. If you don't see the Application Passwords section in your user profile, your host may have restricted it. Your site may also be running on HTTP rather than HTTPS. App passwords require SSL, and this process breaks down entirely if your site lacks a valid certificate.
Between 6% and 8% of WordPress sites were hacked or infected in 2024-2025 (WPWorth, aggregating Wordfence, Sucuri, Melapress, 2025). App passwords reduce the blast radius of a breach, but they don't replace strong admin passwords, updated plugins, or regular backups. Worth noting the broader gap: 74.3% of published WordPress vulnerabilities in 2024 were patched, leaving 25.7% unpatched (PatchStack via MyCodelessWebsite.com, 2025). Credential hygiene is one layer of protection, not the whole wall.
Key Takeaway: An app password limits what an attacker can do with a stolen credential. Your admin login limits whether they can get in at all. You need both.
Most site owners treat creating an app password as the finish line. It isn't. The credential you generate is only as safe as where you store it. Pasting it into a shared Google Doc, a Slack message, or an unencrypted notes app hands it to anyone with access to those tools. A password manager is the right home for it, full stop.
The other common mistake: creating app passwords for tools you tested once and never used again. Those credentials stay active indefinitely. WordPress does not expire them automatically, and there is no warning system for dormant ones. An unused app password from a tool you abandoned eight months ago is still a working key to your site's REST API.
You revoke a WordPress app password from the same profile page where you created it. Each entry has its own "Revoke" button next to its label. A single "Revoke All Application Passwords" button at the bottom of the section wipes everything at once if you need a clean slate.
Revoke any time you stop using an integration, switch publishing tools, or offboard a team member who had access. Treat unused app passwords like open doors you've forgotten about. They don't expire on their own.
The audit habit worth building: once a quarter, open the Application Passwords list on your admin account and any other user accounts that have connected external tools. Delete anything you don't recognize or no longer use. The label you wrote at creation is the only clue you'll have, which is exactly why naming them precisely matters so much at setup.
The tradeoff here is a genuine gap in the native toolset. WordPress gives you no usage log for app passwords. You can see that a password exists, but not when it was last used or what it accessed. For that level of visibility, you'd need a security plugin like Wordfence or a server-level access log. That's a limitation worth knowing before you rely on the built-in interface alone.
86% of businesses now use multi-factor authentication for at least some accounts (Microsoft Digital Defense Report via SEOSandwitch.com, 2025). Regular app password audits deserve the same discipline. The rigor companies apply to MFA lifecycle management should apply to every API-level credential touching your site.
Key Takeaway: A quarterly credential audit takes ten minutes and closes the doors you forgot you opened.
Open your WordPress dashboard, go to Users → Your Profile, scroll to the Application Passwords section, and create one labeled with the name of the first tool you want to connect. That single action separates your admin credential from every external integration touching your site.
If you want a publishing workflow that handles this connection for you, Acta AI walks you through the WordPress setup step by step, connects via app password, and starts publishing automatically. No developer required.
This approach breaks down when constraints are tighter than expected or local conditions shift quickly.
The tradeoff is clear: structure improves consistency, but flexibility matters when assumptions fail. If friction increases, reduce scope to one priority and re-sequence the rest.