Chapter 13 — Can You Begin Recovery Even If Identity Is Dead?

13.1 A Path Is Needed to Begin Recovery

In Chapter 12, we saw that Recovery is a problem of dependencies, and that a dependency can obstruct Recovery for at least two distinct reasons: being "unavailable" and being "not yet trustworthy."

Among these, when identity or the administrative path itself becomes the object in question, a particular problem arises. Depending on the target, administrative authority or an administrative path may be needed to proceed with Recovery. If that administrative path is unavailable, or not yet trustworthy, it may not be possible to begin Recovery through the normal path.

In this book, we sometimes call this "path for beginning Recovery" the bootstrap path.

However, this is a term this book uses to explain this idea, not standard terminology established by NIST, CISA, or NCSC.

In Recovery design, it is considered desirable to have a path available for beginning Recovery from a state in which normal identity or the administrative path is unavailable, or not yet trustworthy.

13.2 When the Normal Administrative Path Is Unavailable

The first situation is one in which the normal administrative path itself becomes unavailable.

For example, the identity mechanism itself may be experiencing a failure, or it may not be functioning, making the administrative path always used inaccessible. In this case, you cannot even reach the starting point for beginning Recovery.

13.3 When the Normal Administrative Path Is Not Yet Trustworthy

The second situation is one in which the normal administrative path itself is running, but it is not yet trustworthy.

In a state where it cannot be confirmed that the administrative path, or the principal accessing through it, has not been compromised, even if you can technically log in, you cannot say it is acceptable to use it for Recovery as-is.

Being "unavailable" and being "not yet trustworthy" are separate problems. The distinction we saw in Chapter 12 applies here just as it did there. This book does not go as far as assigning a separate technical solution to each of these two situations. In either situation, the normal path cannot be used as-is, which is where the idea covered next comes in.

13.4 Emergency Access / Out-of-Band Recovery Access

To prepare for the case where the normal administrative path is unavailable or not yet trustworthy, having a dedicated emergency Recovery Access — Emergency Access — available through a path different from the normal one (out-of-band) can help maintain recoverability.

Here, "a path different from the normal one" simply means "a path other than the usual one"; this book does not specify whether that concretely refers to an offline environment, a physically separate network, or a separate authentication foundation. What form this actually takes varies by organization.

In Chapter 10, we confirmed that because Emergency Access itself carries strong authority, it requires independent control. This chapter takes that idea further, into the problem of beginning Recovery.

There is something we want to make clear here.

Emergency Access is not an all-powerful administrator account.

Emergency Access is not:

• a permanent super-admin account with unlimited authority at all times
• a universal bypass mechanism that can ignore every control
• a magic solution that, by itself, resolves every dependency for Recovery
• proof that the whole environment is trustworthy, simply because it can be used

Emergency Access is, at most, one possible means of beginning Recovery. Note that its existing does not, by itself, mean Recovery will succeed.

13.5 Emergency Access Itself Also Has Dependencies

Emergency Access is not only not all-powerful in itself; it is also built on top of several dependencies of its own.

Recovery architecture needs to confirm whether Recovery can actually be begun when normal identity, credentials, keys, documentation, and administrative tooling are unavailable or untrustworthy.

In other words, even if you try to begin Recovery using Emergency Access, if the credentials, cryptographic material, or procedural information needed for it are not in place, you may in the end be unable to begin Recovery at all.

Credential, key, and secret are each different concepts. Here too, they cannot be treated as the same thing. The idea of protecting each of them individually, as we saw in Chapter 9, remains unchanged in this chapter.

Here, we confirm only that Emergency Access itself can depend on elements like these; we do not design the protection method for each one again.

13.6 Governing Emergency Access Itself

Because Emergency Access is itself a mechanism holding powerful privilege, it requires its own governance.

As confirmed in Chapter 10, Emergency Access needs a bounded lifecycle and independent control. It should not be left in place unattended.

There is a point to note here. This idea of "independent control" should not be casually extended into a specific technical implementation requirement. For example, this book does not go as far as saying that requirements such as the following are universally necessary:

• always having a separate Identity Provider, independent from normal identity
• Emergency Access always having to be stored offline
• never federating it with normal systems
• always having to use a different authentication foundation or network

These can be valid design choices depending on the situation, but what the information underlying this book directly supports is, at most, the more general idea of "having a bounded lifecycle" and "being independently controlled."

It is also considered that being able to grasp and confirm, in some form, how Emergency Access is used should be part of independent control. However, this chapter does not cover concretely how to record or monitor this.

13.7 Connecting to the Next Recovery Plan

So far, we have thought about the path itself needed to begin Recovery.

What matters is that the existence of dependencies does not automatically determine a single order for beginning Recovery. This book does not support a fixed rule such as "Identity must always be recovered first." Nor is there a universal recovery order between things like DNS, Network, and Storage.

Also, if the path itself needed to begin Recovery depends on other dependencies, a circular problem can arise — one element needing another to come back, and that other element in turn needing the first to come back. This chapter confirms only that this kind of circular problem can exist regarding identity and administrative paths.

Once Recovery can actually be begun using a mechanism like Emergency Access, concretely what order to proceed with Recovery in is covered again in a later chapter.

13.8 Summary

This chapter organized the question of how to begin Recovery from a state where the normal administrative path is unavailable or not yet trustworthy.

The important points are these:

• Depending on the target, administrative authority or an administrative path may be needed to proceed with Recovery, and if that path itself is unusable, Recovery may not be able to begin.
• The normal administrative path being "unavailable" and being "not yet trustworthy" are separate problems.
• Emergency Access (out-of-band recovery access) is one means that can help maintain recoverability, but it is not an all-powerful administrator account.
• Emergency Access itself is also built on dependencies such as credentials, keys, documentation, and administrative tooling.
• Emergency Access requires a bounded lifecycle and independent control.
• Emergency Access existing does not, by itself, guarantee the success of Recovery or the trustworthiness of the environment.

Representative Perspectives to Confirm in This Chapter

Let's organize what we've covered so far into a simple table.

This table organizes what needs to be considered for each situation; it does not recommend a specific implementation approach.

Questions to Consider After Reading Chapter 13

Thinking about the systems you are responsible for, can you answer the following questions?

1. Why are the normal administrative path being "unavailable" and being "untrustworthy" separate problems?
2. Why should Emergency Access not be thought of as simply an all-powerful administrator account?
3. What kind of problem can arise if the path itself needed to begin Recovery depends on things like credentials or keys?
4. Why does this book not fix Emergency Access to a single concrete implementation approach?
5. Why are Emergency Access existing and it being usable in an actual incident not the same thing?

You do not need to be able to answer all of them.

Rather, if there is a point where you get stuck, that is exactly the point this chapter is meant to help you check.