What is the Red Envelope Procedure?
The Red Envelope procedure is a documented emergency access procedure in which administrator passwords, recovery codes and other critical access credentials are sealed and stored offline, so that they can only be used during a severe incident, under supervision and with mandatory renewal afterwards. The “red envelope” is literally a physical, sealed envelope in a safe, or a digital equivalent. In OT environments the procedure is part of Contingency Planning: it ensures that an organisation can keep operating its PLCs, SCADA servers and network equipment when normal access is lost, for example due to Ransomware, a failed domain controller or sabotage.
The term is not a standard or legal concept but a house name for a specific form of break-glass access: the emergency variant that does not depend on the network, the directory or the password management system that may be unreachable precisely during the crisis.
🧠 How does the Red Envelope procedure work?
The procedure follows a fixed life cycle. Each phase has its own owner and its own evidence for the audit.
| Phase | What happens? | Evidence |
|---|---|---|
| 1. Create | Emergency accounts and recovery codes are created, with long unique passwords that nobody memorises | Inventory list per system |
| 2. Seal | Credentials go into a tamper-evident envelope or bag with a serial number, inside a safe | Register with seal number, date and two signatures |
| 3. Store | Two sets at separate locations, for example the control room and head office | Key or combination management for the safe |
| 4. Open | Only on a predefined trigger and with the approval of at least two people | Incident number, time, names |
| 5. Use | Only the actions needed to restore normal access | Logging on the system and a handwritten log |
| 6. Renew | All credentials used are changed immediately and resealed | New seal number, review report |
The principle is simple: an intact seal proves that nobody has seen the credentials. A broken seal without an incident number is therefore a security incident in its own right.
🎯 Why is emergency access in OT different from IT?
In office IT, emergency access is often a cloud or directory account that sits outside the normal access rules. In OT other factors apply:
- Availability comes first - an installation that stops or becomes uncontrollable can create safety and environmental risks. Waiting for a supplier to restore access is not always an option.
- Many local accounts - PLCs, HMIs, switches and an Engineering Station often have their own local passwords or project passwords that are not linked to Active Directory.
- Dependencies fail together - if ransomware encrypts the domain controller and the password vault, digital emergency access is gone too. A paper envelope in a safe needs no power, network or licence server.
- No automatic expiry - many field devices do not support temporary or emergency accounts. The OT discussion for control AC-2(2) of NIST SP 800-53 (from the OT overlay in NIST SP 800-82 Rev. 3) states that the automatic disabling requirement then does not apply, and names non-automated procedures as a compensating control.
This is why the procedure is most common in sectors with high availability and Compliance requirements, such as energy, chemicals, water and pharmaceuticals.
🔄 How does it differ from break-glass access and a password vault?
The Red Envelope is not an alternative to good password management but the safety net underneath it.
| Method | Core idea | Works when network or directory is down? | Typical use |
|---|---|---|---|
| Red Envelope | Sealed, offline emergency credentials, opened by two people | Yes | Last resort in a total lockout |
| Break-glass account | Dedicated emergency account outside the normal access rules, with an alert on every use | Only if the account is local or independent | Outage of MFA or the identity provider |
| Password vault / PAM | Digital vault with check-out, session recording and rotation | No, depends on its own infrastructure | Day-to-day management of admin accounts |
In practice you combine them: daily work runs through PAM, while the PAM administration accounts and the local emergency accounts sit in the red envelope. That way the PAM platform itself also has a recovery route.
🏭 Which systems and credentials belong in the envelope?
Include only what is needed to regain control of the process. Every extra line is extra risk.
| System | Typical content | Point of attention |
|---|---|---|
| PLC and SIS | Project password, CPU protection password | Changing it often requires a download; plan this with the process owner |
| SCADA, DCS and HMI servers | Local administrator account, BIOS and disk encryption codes | Disk encryption recovery keys belong here too |
| Firewalls and switches | Local admin account, console password | Without a network, console access is the only route |
| Domain and PAM | Active Directory recovery account, password vault admin account | Must be independent of federation or the directory itself |
| Backup environment | Access to immutable backups | Essential for Disaster Recovery after ransomware |
Supplier access for remote maintenance should in principle not be included. Arrange temporary supplier access through a separate, logged process in line with Supplier Security.
🔧 How do you set up a Red Envelope procedure?
A workable approach in six steps:
- Define the triggers - record when opening is allowed: lockout of critical systems, outage of the directory or PAM, a ransomware incident or an instruction in the Incident Response Plan. A forgotten password on a Tuesday afternoon is not a trigger.
- Assign roles - who may open the envelope (for example the shift supervisor on duty plus the OT security officer), who must be informed immediately and who leads the review.
- Choose storage and redundancy - at least two sets at separate locations, in fireproof safes. Microsoft gives the same advice for emergency accounts in Entra ID: at least two accounts, not tied to one person, with credentials in fireproof safes at separate locations.
- Make use visible - set up Security Monitoring and alerting on every sign-in with an emergency account. An alert without an ongoing incident is a sign of misuse.
- Test regularly - check at least every 90 days that the accounts still work and that the list of authorised people is correct, and rehearse the full procedure at least once a year during a crisis exercise. Change the safe combination when someone with access leaves.
- Renew after every use - change all passwords used, reseal with a new seal number and run a review, linked to Change Management.
Typical values in practice: passwords of 20 characters or more, two people to open, a separate register per envelope and a review at every staff or system change.
🔐 What risks and controls come with it?
A badly managed envelope is a back door rather than a safety net.
- Outdated credentials - a system is replaced or a password changed, but the envelope is not. Link every change to Change Management and test periodically.
- Unnoticed opening - use numbered, tamper-evident seals and check them at every inspection.
- Excessive privileges - combine with Least Privilege and Access Control: an emergency account only gets the rights needed for recovery, not domain-wide rights by default.
- Shared accounts without traceability - recording who opened the envelope and what happened is required for forensic investigation and Compliance.
- Dependence on the same infrastructure - a “digital envelope” in a vault running on the same network is also unreachable during a ransomware attack.
Good Security here means that the emergency route is as well controlled as the normal one.
📜 Which standards and laws require emergency access?
No standard prescribes the name “Red Envelope”, but many frameworks do require controlled emergency access:
| Framework | Relevant requirement |
|---|---|
| NIS2 Article 21 | Business continuity, backup management, disaster recovery and crisis management, plus access control policies |
| Cybersecurity Act | Dutch implementation of NIS2, in force since 15 August 2026 |
| ISO 27001:2022 | Controls for privileged access rights (8.2), authentication information (5.17) and logging (8.15) |
| IEC 62443 / IEC 62443-2-1 | Security programme for OT asset owners, based on the principle that security must not block essential process functions |
| NIST SP 800-53 AC-2(2) | Automatically disable or remove temporary and emergency accounts after a defined period |
| NIST SP 800-82 Rev. 3 | OT overlay on the SP 800-53 controls: allows procedural compensating controls where field devices do not support emergency accounts |
❓ Frequently asked questions
Is a Red Envelope procedure the same as break-glass access?
A Red Envelope procedure is a specific form of break-glass access. Break-glass is the umbrella term for any documented emergency access, while the red envelope is the offline, physically sealed variant that still works when the network, directory and password vault are down.
May an emergency password be stored on paper?
Yes, an emergency password may be stored on paper if it sits in a numbered, tamper-evident envelope inside a locked safe and every opening is recorded. Paper has the advantage that it needs no network, power or licence server during a cyber incident.
How often should you test the Red Envelope procedure?
Check the emergency accounts from the Red Envelope procedure at least every 90 days and after every staff or system change. Rehearse the full procedure, including opening, use and resealing, at least once a year during a crisis exercise.
What must happen after the envelope has been opened?
After the envelope has been opened, all credentials used are changed immediately, resealed under a new seal number and recorded in the register. A review then establishes whether the use was justified and which actions were performed with the emergency account.
Who may open the red envelope?
The red envelope may only be opened by designated officers, preferably two people together, such as a shift supervisor and the OT security officer. The four-eyes principle prevents a single person from obtaining full administrative rights unnoticed.
Does a PAM solution replace the Red Envelope procedure?
No, a PAM solution does not replace the Red Envelope procedure, because the PAM system itself can also fail or be encrypted. The PAM platform’s administration accounts therefore belong in the red envelope, so that you can restore the safety net as well.
📌 In summary
The Red Envelope procedure is documented, offline emergency access to critical OT systems: stored sealed, opened only by two people during a defined incident and renewed immediately after every use. It keeps an installation recoverable when normal access is lost, without the emergency credentials becoming a permanent back door.
- Keep at least two sets at separate locations, independent of the network, directory and password vault
- Include only the credentials needed to restore control, with minimal privileges
- Test every 90 days, rehearse yearly and renew after every use
- Embed the procedure in the Incident Response Plan, Disaster Recovery and Business Continuity