How-to: Setting up emergency access without making it a security hole

Great question - this is super important for small teams. 1Password Business has a dedicated "Emergency Kit" feature for exactly this scenario.

You can assign specific people (like a co-founder or ops lead) as emergency requesters. They won't see the passwords until they formally request access, and you get a notification to approve or deny. If you don't respond after a set waiting period you choose (like 24 or 72 hours), access is automatically granted to them. That delay is your safety net.

Just make sure those emergency contacts have strong, unique master passwords and 2FA on their own accounts. The real trick is testing the process once with a dummy vault - that way everyone knows how it works before you need it for real 😅

That exact scenario kept me up at night before we set ours up! You're smart to focus on the "without making a security hole" part.

The Emergency Kit feature user1376 mentioned is definitely the way to go. My big addition is to pick emergency requesters who are *outside* the engineering/infra function if you can. Like a co-founder in finance or ops. They're less likely to be a daily target for phishing, and they have a different risk profile. Giving emergency access to another engineer who already has high-level system access can sometimes create a single point of failure in a different way.

Also, be super deliberate about the waiting period. We started with 24 hours but realized that wasn't enough time to account for me being on a long flight or camping trip without service. We moved it to 48. It feels like a long time in a panic, but the delay is the whole point. You have to balance "real emergency" with "I'm just temporarily offline." Definitely do the practice run!

Thanks for explaining the Emergency Kit, that makes sense. Testing with a dummy vault is a great callout. I'm curious about the actual mechanics though: when someone requests access and the waiting period starts, what's the exact chain of notifications? Does it just rely on your email, or does 1Password also send a push alert to your phone or something? I'd hate for the safety net to fail because an email got buried or went to spam.

Good question, it's exactly what we checked when we set ours up. It does send both an email *and* a push notification to the 1Password app on your phone, provided you have notifications enabled. So there's a dual channel.

But you've hit on the real weak spot - if you're the only one who gets that notification and you're the one incapacitated, the system still relies on someone else knowing to *start* the emergency request. That's why our team rule is: if I'm unreachable for X hours on a critical issue, the trigger to *use* the emergency process is discussed in our runbooks. The tech works, but the human process around it is just as important.

Testing with a dummy vault is the only part I agree with. The rest assumes you'll be conscious to respond. If you're hit by a bus, that "safety net" waiting period becomes a hard deadline before anyone can even start fixing things.

The real gap is the *trigger*. Someone has to know you're gone *and* know the process exists. That's a human problem tech won't solve. Write the damn runbook. Put the fact that emergency access exists in a known, shared place, not just in 1Password's feature list.

You're right to focus on the steps, as the setup is where most people make mistakes. The Emergency Kit feature is your tool, but configuring it poorly can create the exact security hole you're worried about.

Go to Settings > Accounts > Emergency Access. Pick two emergency requesters - not from your same engineering circle. Set the waiting period to at least 48 hours. The real step everyone forgets is to then create a separate vault *just* for those emergency AWS/Terraform secrets and share it with those requesters *through the Emergency Kit*, not regular sharing. That way the access is solely gated by the emergency workflow.

Test it immediately by having one requester go through the process. If you don't test, you've just built another piece of brittle infra.

Creating a separate emergency vault is still putting all the eggs in one basket, just a different one. Now you've got a vault that sits there, quietly waiting for the emergency protocol to fail or be forgotten.

The real move is to split the secrets. AWS root creds go to one designated person, Terraform state access to another. They can't trigger a full takeover unless they collude. It's messier, but it doesn't rely on a single 'kit' that nobody remembers to check.

You need both the tech and the process. Everyone else is covering the 1Password steps, so I'll give you the numbers.

When we set this up, we measured the time from incident declaration to vault access. Without a documented trigger process, the waiting period is useless. Our first dry-run took 12 hours just for someone to realize they should *start* the 1Password request. The tool works if you know to use it.

Document the trigger in your runbook. Define "unreachable" (e.g., no response on call/Slack for 1 hour during a P1). List the emergency requesters by name. Then test the *entire* flow, from declaring the emergency to accessing a dummy secret. If you skip the dry-run, you're building unknown failure modes.

Exactly. The weak spot is the trigger. Tech can't fix a human process gap.

Our rule is simple: if the primary contact is unresponsive to a P1 alert for 30 minutes, the escalation runbook is opened. Page 1 is the 1Password emergency request process. The notification delay is irrelevant if no one knows to pull the lever.

We learned this the hard way when our sole admin took a long weekend. The system was fine, but no one knew how to start it.

The step-by-step settings are in 1Password's admin console under Emergency Access. You pick requesters, set a delay, and define a vault.

But you're worrying about the wrong hole. The security hole isn't a misconfigured checkbox; it's having a process that only exists in your head. Configure the feature perfectly, then write a runbook that tells someone *when* to use it. If they don't know it exists until after you're gone, the settings are irrelevant.

That's a good point about the runbook. But where do you even put it so people will find it? If the runbook is in a team wiki no one reads, you've got the same problem.

Do you pin it somewhere obvious, like a shared drive everyone has open, or make it part of onboarding for specific roles?