The deploy account is a master key: whoever holds it can run code as administrator on every workstation you manage. That power is exactly why PDQ Deploy works — and exactly why the account deserves deliberate setup instead of your personal admin login typed in once and forgotten.
PDQ Deploy stores the deploy account's credentials (encrypted in its database) and uses them to connect to every target. The video's requirement is real: the same account must be a local administrator on all systems. The question is how to satisfy that requirement without creating a skeleton key to your whole office. Four decisions do it.
Create a separate account used only by PDQ Deploy — for example a domain account named clearly for deployment. Your own admin login must never be the deploy account: it goes everywhere you go, gets typed at keyboards, and when you change your password (or leave the job), every deployment in the office breaks at once. A dedicated account has one job, one owner, and a password that changes on a schedule, not on someone's life events.
The account needs local administrator rights on the target PCs — that is what installing software requires. It does not need Domain Admin rights, server rights, or mailbox access, and it should never get them. On a domain, grant the rights cleanly with Group Policy (add the account to the local Administrators group of workstations only). Least privilege is not decoration here: a workstation-only account that leaks can hurt your PCs; a Domain Admin that leaks owns your servers, your data and your backups in the same hour.
PDQ supports LAPS (Windows Local Administrator Password Solution), where every PC's local admin password is unique and managed by Active Directory, and PDQ retrieves the right one per target. It is more setup than a shared deploy account, and it removes the single-password-to-every-PC risk entirely. Small offices often start with the dedicated shared account and graduate to LAPS; the honest point is to know the shared account is a calculated risk you are managing, not a risk that does not exist.
If you also run PDQ Inventory, resist using one account for both. The Inventory scan account only reads; the Deploy account can write and execute. Separate accounts mean a problem with one does not hand over the other's power, and your logs can tell reading from changing. The Inventory batch in this blog series covers scan-account safety in the same spirit — least privilege, dedicated identity, watched closely.
The video shows the account requirement in action across many systems — pair it with these rules and the same setup stays safe at 10 PCs or 200.
▶️ Watch Full VideoYou can, and it will work — that is the trap. It ties all deployments to your personal password, spreads your most powerful credential into another database, and hands over far more rights (including servers) than deployment needs. A dedicated workstation-scoped account does the same job with a fraction of the blast radius.
No. PDQ encrypts the credentials stored in its database. That protects the stored copy, but it does not reduce what the account itself can do — which is why scoping the account's rights matters more than the storage detail.
Deployments start failing with access-denied errors until you update the password in PDQ Preferences → Credentials. Change it there in the same maintenance window, then run a small test deployment to prove the fleet still answers.