Shared Account Authentication
MFA for shared accounts — without sharing authentication devices
Add multi-factor authentication to shared VPN and remote access accounts — while maintaining individual accountability. Multiple team members share the same login credentials, but each person authenticates with their own phone or hardware token. The audit log shows exactly whose device was used for each login.
One Account, Multiple Authenticators
Traditional MFA ties one phone or token to one account. Shared Account Authentication links multiple phones and tokens to a single account. When logging in via RADIUS, the user is prompted to enter their phone number or token ID — Mideye validates it belongs to the account and sends the MFA challenge to that device. The selection is recorded in the audit log. Administrators can configure accounts through the admin portal.
Shared Account Authentication works on any system that authenticates via RADIUS — VPNs, firewalls, remote desktop gateways, SSH (via PAM), and similar. The user enters the shared password, then Mideye sends a RADIUS challenge asking which phone or token to use for the second factor.
When Should You Use Shared Account MFA?
Vendor & MSP VPN Access
External vendors sharing a single VPN account for remote maintenance. Each vendor employee uses their own phone to authenticate — and you see exactly who connected. Supply chain security with full accountability. For real-time approval of vendor sessions, see Assisted Login.
Shared Admin VPN Accounts
IT teams sharing a privileged VPN or remote access account. Each admin authenticates with their personal device while using the shared credential. Full audit trail for compliance frameworks like NIS2 and DORA.
Shift Work Remote Access
Operations teams sharing a single remote access account across shifts. Each operator uses their own token or phone — the audit log shows who was on shift and when they connected.
Shared SSH / Linux Accounts
Shared root or service accounts on Linux servers authenticated via PAM RADIUS. Each person identifies themselves with their own phone or token before access is granted.
How Does Shared Account Authentication Work?
Configuration
- Create a Mideye user with authentication type Shared Account (10)
- Add multiple phone numbers and/or token serial numbers to the user's "Other Mobiles" field
- When the user logs in via a RADIUS-enabled system, Mideye sends a challenge asking for their phone or token number
- Mideye validates the response is in the registered list, then sends the MFA challenge (push or token OTP)
- Audit log records the account name and the specific device used
What Authentication Methods Are Supported?
How Does Shared Account MFA Improve Security?
- Individual accountability — Audit log shows exactly which phone or token was used, not just the shared account name
- No shared secrets — Each person uses their own device. No shared phones, no shared tokens, no shared OTPs
- Device registration — Only pre-registered phones and tokens can authenticate. Can't use arbitrary devices
- Easy offboarding — Remove a team member's phone from the list when they leave. No password changes needed
- Compliance ready — Per-person audit trail on shared accounts helps meet access logging requirements in security frameworks and audits
Supply Chain Security
Third-party vendors sharing a VPN or remote access account is a common attack vector. Shared Account Authentication ensures every vendor login is tied to a specific person's device — even when using a shared credential.
Combined with Assisted Login, you can require internal approval before vendors can authenticate with the shared account.
What Compliance Requirements Does This Address?
Shared Account Authentication addresses regulatory requirements for privileged access management and least privilege.
🏦 DORA RTS Article 21 — Need-to-Use Basis
Requirement: "Assignment of privileged... access on a need-to-use or an ad-hoc basis."
How Mideye addresses this: Time-based access windows combined with per-person MFA ensure privileged accounts are only accessible during approved maintenance windows. Access automatically expires—no standing privileges.
🔒 ISO/IEC 27001:2022 — Annex A 5.15 & A.5.18
Requirements: Access control policies (A.5.15) and privileged access rights management (A.5.18).
How Mideye addresses this: Shared Account Authentication provides individual accountability on privileged accounts. Audit logs show exactly who accessed the shared account and when, supporting least privilege enforcement and access reviews.
🇪🇺 NIS2 & PCI DSS — Shared Account Management
Shared accounts are explicitly discouraged by most frameworks, but when operationally necessary, they must have individual accountability.
How Mideye addresses this: Per-person MFA on shared credentials provides the audit trail required to identify who performed which action, even when multiple people share the same username.
Best practice: Prefer individual accounts over shared accounts whenever possible. When shared accounts are operationally necessary (appliances, legacy systems, vendor access), Shared Account Authentication provides the individual accountability layer required by compliance frameworks. See our compliance hub for complete framework mappings.
Add MFA to Your Shared Accounts
Shared Account Authentication is included with Mideye Server 5.6 and later. Contact us to discuss your shared account security requirements.
Contact Sales →