Best Two-Factor Authentication Setup for Remote Team Shared Accounts

When your remote team relies on shared accounts for services like AWS, GitHub, or production dashboards, a single password is a single point of failure. Someone shares credentials over Slack, a team member leaves with knowledge of the password, or worse—a compromised credential gives attackers full access to your infrastructure. Two-factor authentication (2FA) adds a critical second layer of defense, even for accounts that multiple people need to access.

This guide covers practical approaches to implementing 2FA for shared accounts in remote teams, with concrete examples you can apply today.

Understanding the Shared Account Problem

Shared accounts exist because some services don’t support team-based access control. You might need a single AWS IAM user for deployment pipelines, a shared Slack bot account, or admin access to a legacy CMS. The challenge is clear: you need multiple people to access the same credentials, but you also want the security benefits of two-factor authentication.

The solution isn’t one-size-fits-all. Different 2FA methods offer different tradeoffs between security, convenience, and recovery options. Let’s walk through the most practical approaches.

Method 1: TOTP-Based 2FA with Shared Secret Storage

Time-based One-Time Passwords (TOTP) are the most common 2FA method. Services like Google Authenticator, Authy, or 1Password generate short-lived codes based on a shared secret. For shared accounts, you store the secret in a secure, accessible location.

Setting Up TOTP for a Shared Account

Generate a TOTP secret and store it in your team’s password manager:

# Install oathtool for generating TOTP secrets
brew install oath-toolkit

# Generate a new TOTP secret
oath-toolkit totp -s -a SHA1 30 mycompany_shared_aws

# This outputs something like:
# JBSWY3DPEHPK3PXP

Share the secret through your team’s 1Password, Bitwarden, or HashiCorp Vault. Each team member generates the same TOTP code from the shared secret. When someone needs to log in, they open the authenticator app, select the shared account, and enter the current code.

This approach works well when your team uses the same authenticator app. Authy makes this especially easy by syncing secrets across devices, while 1Password can store and generate TOTP codes directly.

Pros and Cons

Pros:

• Works with most services that support TOTP
• No hardware requirements beyond smartphones
• Codes change every 30 seconds, limiting window of vulnerability

Cons:

• If someone gains access to the shared secret, they can generate codes
• Recovery requires access to the stored secret
• Not all password managers support TOTP generation from shared vaults

Method 2: Hardware Security Keys (YubiKey)

Hardware security keys like YubiKey provide the strongest 2FA protection. Instead of a shared secret that multiple people possess, each team member has their own hardware key registered to the shared account.

Registering Hardware Keys

Most major services support multiple 2FA methods. For AWS IAM:

# Using AWS CLI to enable MFA for an IAM user
aws iam enable-mfa-device \
  --user-name shared-deploy-bot \
  --serial-number arn:aws:iam::123456789012:mfa/yubikey1 \
  --authentication-code1 123456 \
  --authentication-code2 789012

Register each team member’s YubiKey to the same account. When anyone needs to authenticate, they plug in their specific hardware key and tap to generate a code.

The Security Advantage

Hardware keys resist phishing because they cryptographically verify the service’s origin. Even if an attacker creates a fake login page and intercepts the password, they cannot complete authentication without the physical key. This matters especially for high-value shared accounts like AWS root or production database access.

Pros and Cons

Pros:

• Highest security level available
• Each team member has individual authentication
• Easy to revoke access (just remove one key)
• Phishing-resistant

Cons:

• Upfront cost ($50-70 per key)
• Requires physical access to the key
• Not all services support hardware 2FA
• Team members must have their own keys

Method 3: Centralized Identity with SSO

If your team uses Google Workspace or Microsoft 365, you can use SSO for many services. However, for services that don’t integrate with your identity provider, consider using a centralized authentication proxy.

Using Authelia or oauth2-proxy

Authelia acts as an authentication gateway. Configure it in front of services that lack built-in 2FA:

# authelia/configuration.yml
configuration:
  jwt_secret: your-jwt-secret-here
  authentication_backend:
    file:
      path: /config/users.yml

  access_control:
    default_policy: two_factor
    rules:
      - domain: "deploy.yourcompany.com"
        policy: two_factor

  session:
    secret: your-session-secret
    expiration: 3600

  notifier:
    disable_startup_check: true

With this setup, users authenticate through Authelia with 2FA (TOTP, WebAuthn, or mobile push), and Authelia proxies the request to the actual service. The shared account credentials are stored securely in Authelia and never exposed to end users.

Pros and Cons

Pros:

• Single authentication point for multiple services
• Fine-grained access control
• Full audit logs of who accessed what
• Supports various 2FA methods

Cons:

• Additional infrastructure to maintain
• Single point of failure if misconfigured
• Requires service support for proxy authentication

Method 4: Delegated Access with Temporary Credentials

For AWS specifically, avoid shared accounts altogether by using IAM roles with temporary credentials. Each team member authenticates with their own identity, then assumes a role with the necessary permissions.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:user/deploy-user"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": {"aws:MultiFactorAuthPresent": "true"}
    }
  }]
}

This ensures every action is traceable to an individual, while still allowing the same permission scope as a shared account.

Best Practices for Remote Teams

Regardless of which method you choose, follow these security principles:

1. Use a password manager — Never share passwords over chat or email. Store them in 1Password, Bitwarden, or HashiCorp Vault.

2. Rotate secrets regularly — Set calendar reminders to rotate shared TOTP secrets and passwords quarterly.

3. Maintain a recovery plan — Document exactly what happens if someone loses their 2FA device. For hardware keys, designate backup keys stored securely.

4. Enable audit logging — Use services that log which 2FA method was used and from what IP address.

5. Limit shared accounts — Proactively migrate services to proper team-based access. Many tools now support SSO or built-in team management.

Choosing Your Approach

Start with TOTP if you need something quick and don’t have hardware keys. Move to hardware security keys for high-value infrastructure accounts like AWS, GCP, or production database access. Implement an auth proxy like Authelia when you need to secure multiple services with a single authentication flow.

The best two-factor authentication setup for your remote team is one that balances security with accessibility. Evaluate your highest-risk shared accounts first, implement the appropriate 2FA method, and gradually improve coverage across your entire tool stack.

Related Articles

• How to Handle Two Factor Authentication Apps When Changing
• Certificate Based Authentication Setup for Remote Team VPN
• Monitor Setup for Remote Developer
• Password Rotation Policy Setup for Remote Teams Using
• Shared Inbox Setup for Remote Agency Client Support Emails

Built by theluckystrike — More at zovo.one