Accounts can be shared.
Identities can't.
The shared "Administrator" account can stay in use. Everyone signing in verifies with the code on their own phone; even though the Windows account stays the same, the records show who signed in, when, and from where — under the real person's name. Access is named and revoked in one click.
A shared account may not be your choice; sometimes it's unavoidable.
"Give everyone their own account" is good advice — but in these four situations it's often simply not possible.
One admin account, several IT staff connecting to it. As servers multiply, multiplying accounts becomes unmanageable.
The accounting or ERP software is installed under a single Windows profile; everyone who uses it has to sign in with the same account.
One operator account on the production or operations workstation; the morning shift and the night shift use the same session.
Multiple technicians connecting to a customer's server with the same admin account — all of them on another company's payroll.
Because most of the time it doesn't work: the software is tied to one profile, the device is configured around one account, and dozens of machines times dozens of people means account sprawl. Where possible, personal accounts and least privilege remain the first choice — Dynacop doesn't replace them; for accounts that must stay shared, it provides per-person verification and a named audit trail.
Account-centric MFA's silent assumption: one account = one person.
Products that resolve identity from the Windows username must map the account to a single enrolled user. On a shared account, that leaves three bad options.
Duo's own documentation, for instance, requires the Windows username to match an enrolled Duo user or a unique alias — a shared account can be tied to at most one person. Dynacop resolves identity from the code that was entered, not from the account: the code is generated from the secret of that person's verified enrollment; that's what makes everything on this page possible.
No person picker — your code carries your identity.
No user list, no extra selection. Everyone enters their password and code as usual; Dynacop resolves who signed in from the code.
The 6-digit code is generated by each person's own authenticator. Dynacop matches the entered code against the verified factors of the people who have access — whoever signed in is known.
Authenticators cannot be enrolled at the lock screen; enrollment completes only through a verified invitation link sent to the person's email. Knowing the password doesn't let anyone attach their own phone to the account.
A used code is not accepted a second time within the same time window. If you sign in back-to-back, the system doesn't say "wrong code" — it honestly says "this code was just used".
When the person can't be resolved from a code — for example on an account you've exempted from MFA — Dynacop doesn't guess a name for the record; it clearly shows the record has no person attached.
Failed attempts against a shared account are locked out at the account level — the number of people using the account doesn't multiply an attacker's tries.
Access is named: granted by invite, ends on schedule, revoked in one click.
The console always shows who is behind the shared account — and every grant can carry its own rules.
Give a contractor three weeks of access; when it expires, access ends on its own — nothing for you to remember.
Limit a grant to RDP only or console only. The remote technician can't walk up to the machine; the local operator can't connect remotely.
The moment you revoke access, the person can no longer sign in with that account. The audit history isn't deleted; who signed in and when stays answered.
A person leaves; the shared account stays.
The most expensive day for a shared account is the day someone leaves the team. This is where the difference shows.
As long as MFA is on, knowing the password alone doesn't open the door — offboarding stops being a password operation.
Shared accounts — frequently asked questions
How do you know who signed in?
From the code. Each person's authenticator generates codes from its own secret; Dynacop matches the entered code against the verified factors of the people who have access to the account. The username is shared — the code is personal.
Can someone who knows the password enroll their own phone and impersonate someone else?
No. Authenticators cannot be enrolled at the lock screen; enrollment completes only through a verified invitation link sent to the person's email. Knowing the password is enough for neither sign-in nor enrollment on its own.
What if two people's codes happen to collide?
It's extremely unlikely; if it happens, Dynacop doesn't guess — it denies the sign-in and asks for the next code. We'd rather have you wait 30 seconds than attribute a sign-in to the wrong person.
Can I reuse the same code for two sign-ins in a row?
No; every code is single-use. On back-to-back sign-ins the system doesn't say "wrong code" — it clearly says "this code was just used, wait for the next one".
What do I need to do when someone leaves?
Revoke their access from the console in one click; they can no longer sign in with that account. No shared-password rotation, no re-distribution, no server tour. The audit history remains under their name.
Should I still change the shared account's password?
With MFA on, the password alone doesn't open the door; password hygiene is still yours to keep, though — Dynacop never sees or manages your passwords. For accounts you've exempted from MFA, rotating the password remains important.
Is using a shared account recommended from a security standpoint?
Where possible, personal accounts and the principle of least privilege are always the first choice; Dynacop doesn't replace them. For accounts that must stay shared for technical or operational reasons, it provides MFA, per-person access, and a named audit trail — it doesn't encourage shared accounts, it makes them auditable.
Does this work for both RDP and console sign-ins?
Yes, both. You can even scope access by protocol: RDP-only for the remote contractor, console-only for the operator at the machine. The full MFA policy story: Windows Login MFA.
How is this different from account-centric MFA products?
Account-centric products resolve identity from the Windows username: the username must map to a single enrolled user or a unique alias. A shared account can be tied to at most one person, so per-person records can't exist in that model. Dynacop resolves identity from the code, so that limit doesn't apply.
Your first 10 users are free.
See the person behind the shared account today.
No credit card required · No minimum purchase