To scan a PC, PDQ's account must be an administrator on it. Multiply that by every computer you manage and you have created the single most valuable credential in the building. This guide treats it that way — because an attacker would.
Think about what the scan user can do: it is a local administrator on every target PC. Whoever holds that password can read files, change settings and — combined with deployment tools — push software across the whole office. Yet in many small networks this account is a shared password written in a spreadsheet, or worse, the Domain Admin account itself. The fixes are not exotic. They are a dedicated account, sensible limits, vault-grade storage, and a rotation habit — applied to the one credential that deserves all four.
Create an account whose only job is scanning — for example svc-pdqscan — and enter it in Options → Credentials. Never scan with your personal admin account: when you change your password, every scan breaks; when you leave the job, the office's inventory leaves with your password. A named service account makes the inventory belong to the organisation, not to a person.
The scan user needs local administrator rights on the target PCs — nothing more. It does not need Domain Admin, and giving it Domain Admin means one leaked password hands over servers, Active Directory and everything else in one step. Place the account into the local Administrators group of your PCs centrally with Group Policy, so the right is exactly scoped: powerful on endpoints, powerless over the domain itself.
In workgroups, or as an alternative design, PDQ supports LAPS accounts as scan users: Windows LAPS gives every PC a unique, automatically rotated local administrator password, and PDQ retrieves the right one per machine. That kills the "one password opens every PC" problem at the root. If you are setting up fresh and your Windows editions support LAPS, this is the strongest pattern available.
The scan password lives in exactly two places: inside PDQ (stored encrypted in its database) and inside the company password manager — never in a spreadsheet, a sticky note or a shared document. Rotate it on a schedule and immediately whenever an admin who knew it leaves. Plan rotations: the moment you change it, update the credentials in PDQ too, or every scan fails until you do — schedule the two changes in the same sitting.
Anyone who can open the PDQ console as a console user operates with the scan account's power, and console users must be local admins on the console machine. So keep that list short and named, put the console on a secured, patched machine rather than a general-purpose PC, and include the PDQ database in your backups — the database holds your inventory and your credential store together.
Because the scan account should only ever act from the console machine, its logons are beautifully predictable — review successful logon events (type 3 network logons) for that account appearing from anywhere else, which is a five-alarm anomaly. And if you ever suspect the password has leaked, you have a clean kill switch: disable the account. Scans stop, nothing else breaks, and you rotate and restore in a controlled way.
Set the dedicated account up once, properly — then the routine scans in the video's tutorial run on a credential you can defend.
▶️ Watch Full VideoYes, the pair commonly shares the credential model — both connect with local admin rights on targets. Apply the same rules, and note the stakes rise with Deploy: the account no longer just reads PCs, it can change them, which makes the dedicated-account and console-access rules more important, not less.
Because PDQ stores the credential you gave it — change the password in Active Directory or on the PCs and PDQ keeps presenting the old one until you update Options → Credentials to match. Always change the password and the PDQ entry in the same maintenance window, then run one test scan.
PDQ stores credentials encrypted in its database, which is the standard design for agentless tools — the alternative would be typing the password for every scan. The practical protection is around the database: a secured console machine, a short console-user list, and backups treated as sensitive files.