up:: Security Basics MOC

Availability

Availability is the security guarantee that information and the systems that carry it stay accessible and usable whenever an authorized user needs them, the third goal of the CIA triad alongside confidentiality and integrity. NIST’s FIPS 199 defines it as “ensuring timely and reliable access to and use of information,” a definition drawn straight from federal law.

Availability is protected mostly by architecture and operations, meaning redundancy, backups, denial-of-service defenses, and disciplined recovery, rather than by the public-key cryptography this Guide is mainly about. That distinction is the reason availability sits apart from its two siblings when it comes to quantum risk: the core quantum threat comes for confidentiality and for the trust behind authentication, and it leaves availability largely alone. The one genuine connection runs the other way. A PKI collapse or a mishandled migration can knock systems offline, so the migration itself is an availability concern to manage.

The short version:

1. Availability is the A in the CIA triad, timely and reliable access to information and systems, defined for all US federal information in FIPS 199.
2. It’s protected by architecture and operations, redundancy and backups, denial-of-service mitigation and capacity planning, and incident response and recovery, with cryptography in a supporting role.
3. Availability failures show up as outages, ransomware lockouts, and denial-of-service floods, and they count as security failures even though no secret was read and no data was altered.
4. The core quantum threat targets confidentiality (through harvesting) and trust (through signature forgery), and it leaves availability largely untouched, so a reader planning a migration shouldn’t over-index on it for post-quantum cryptography.
5. The real quantum link is second-order. A PKI collapse, or expired and un-migrated certificates during a botched rollout, can cause outages, which makes running the migration cleanly an availability responsibility in itself.

Picture an ATM network. Confidentiality is your PIN staying secret, integrity is the balance being exactly right down to the cent, and availability is the machine actually being online with cash in it at 2 a.m. when you need forty dollars. A bank could guard your PIN perfectly and keep a flawless ledger, and still fail you completely if every machine is dark. Availability is that last promise, the one that makes the other two matter to a real person, and cryptography is only a small part of how it’s kept.

What is availability?

Availability is a property of a system and its data: are they reachable and working for the people entitled to use them, right now, when they ask? It’s the operational face of security, and it fails in ways everyone recognizes even without a security vocabulary, a website that won’t load, an app that spins forever, a hospital that can’t pull up records after a ransomware attack. FIPS 199 makes it one of the three security objectives for all US federal information and systems, and it takes the definition directly from the federal statute (44 U.S.C. 3542):

“Availability: Ensuring timely and reliable access to and use of information. A loss of availability is the disruption of access to or use of information or an information system.”

Two words in that definition carry the weight. “Timely” means access has to arrive fast enough to be useful, since a record you can only retrieve after the emergency has passed is functionally unavailable. “Reliable” means it has to hold up consistently, on a bad day as much as a good one. Teams put numbers on this: availability is often expressed as a percentage of uptime, where “three nines” is 99.9 percent (about 8.8 hours of downtime a year) and “five nines” is 99.999 percent (about 5 minutes a year). Recovery targets sharpen it further, with a Recovery Time Objective setting how fast a service must come back after a disruption and a Recovery Point Objective setting how much recent data a recovery may lose, both defined in NIST’s contingency-planning guidance.

The clean way to hold availability against its two siblings: confidentiality is about who can read, integrity is about who can change, and availability is about whether the thing works at all. Every security incident is a failure of at least one of the three, and an availability failure is the one your users feel first.

Source: NIST, “Standards for Security Categorization of Federal Information and Information Systems,” FIPS 199, February 2004, FIPS 199.

Source: NIST, “Contingency Planning Guide for Federal Information Systems,” SP 800-34 Rev. 1, May 2010, SP 800-34 Rev. 1.

How is availability protected?

Availability is protected mainly through how a system is built and run, not through the algorithms that encrypt or sign its data. The defenses cluster into three families, and each maps to a control family in NIST SP 800-53, the federal control catalog:

1. Redundancy and backups. Duplicate components, failover sites, and tested backups mean a single failure, a dead disk, a lost data center, or a ransomware event, doesn’t take the service or the data with it. This is the Contingency Planning (CP) family, and it’s what makes recovery possible rather than aspirational.
2. Denial-of-service mitigation and capacity planning. Traffic scrubbing, rate limiting, and headroom keep a flood of malicious or accidental load from starving legitimate users. NIST calls this out as its own control, SC-5, Denial-of-Service Protection, and SC-6, Resource Availability.
3. Incident response and recovery. Detection, a rehearsed runbook, and clean restore procedures keep an outage short and bounded instead of open-ended. This is where the Recovery Time and Recovery Point Objectives get met in practice.

Cryptography plays a supporting part rather than a starring one, and it’s worth being precise about where it helps. Encrypting backups protects their confidentiality, and hashing or signing a restore image protects its integrity so you know you’re recovering clean data. Neither of those is what keeps the system online. The thing that keeps it online is architecture, and that’s the honest reason availability is a smaller cryptography story than the other two goals.

Availability threat	What it looks like	Primary defense (NIST SP 800-53 family)
Hardware or facility failure	A server, disk, or data center drops offline	Redundancy, failover, tested backups (CP)
Ransomware or destructive attack	Data encrypted or wiped, systems locked	Offline backups, incident response and recovery (CP, IR)
Denial-of-service flood	Traffic saturates a service so real users can’t reach it	DoS mitigation, rate limiting, capacity headroom (SC-5, SC-6)
Capacity exhaustion	Demand outgrows resources, service degrades or stalls	Capacity planning, resource limits, autoscaling (SC-6)
Operational error	A bad change or a lapsed dependency takes a service down	Change control, monitoring, tested rollback (CM, SI)

Source: NIST, “Security and Privacy Controls for Information Systems and Organizations,” SP 800-53 Rev. 5, September 2020, SP 800-53 Rev. 5.

Why does availability matter?

Availability matters because a system that keeps every secret and never corrupts a byte still fails its whole purpose the moment nobody can use it. For most organizations, downtime is the security failure with the most immediate and visible cost, lost revenue, stalled operations, missed care in a hospital, and it’s the one that ends up on the news. Ransomware pushed availability from a back-office reliability concern to a front-line security problem, because a ransomware attack is fundamentally an availability attack: it doesn’t steal your data so much as it takes your access to your own data hostage.

Availability also carries formal regulatory weight. FIPS 199 requires federal systems to be categorized at a low, moderate, or high impact level separately for each of confidentiality, integrity, and availability, and the availability rating drives real requirements for redundancy and continuity planning. So availability is a first-class security goal in the standards, on equal footing with the other two, and treating it as merely an “IT uptime” issue understates what the frameworks actually demand.

Source: NIST, “Standards for Security Categorization of Federal Information and Information Systems,” FIPS 199, February 2004, FIPS 199.

Does the quantum threat attack availability?

Availability is the one core security goal that a quantum computer doesn’t meaningfully threaten through cryptography, and it’s worth stating that plainly so nobody over-plans for it. The quantum threat is specifically a public-key problem. A cryptographically relevant quantum computer running Shor’s algorithm breaks the math behind RSA, ECDH, and the classical signature schemes, which lets it attack two goals:

1. Confidentiality, through Harvest Now, Decrypt Later, where recorded traffic gets decrypted years after the fact.
2. Integrity and authentication, through signature forgery, where a recovered private key lets an attacker mint fake certificates and impersonate trusted parties.

Availability rests on redundancy, capacity, and recovery, and none of those depend on the public-key algorithms Shor’s algorithm dissolves. Grover’s algorithm, the other quantum tool, speeds up brute-force search against symmetric keys, and it has nothing to say about whether a data center is online or a service is reachable. There’s no “harvest-now” version of an outage and no way to forge uptime. So a reader building a migration plan should weight it toward the confidentiality and trust goals and treat availability as a goal the transition mostly passes over. Over-indexing on a quantum-availability threat means chasing a risk that the cryptography doesn’t actually create.

Can the post-quantum migration itself cause an outage?

Here is the honest and only real connection between availability and the quantum transition, and it runs backward from what people expect: the quantum threat doesn’t attack availability, but the response to it can, if the migration is handled badly. This is a second-order effect, an availability risk created by the project rather than by the adversary, and it shows up in two ways.

1. A PKI collapse cascade. If a certificate authority’s signing key is broken, the recovery, revoking the CA, reissuing everything beneath it, and pushing new trust anchors out through update cycles, is itself disruptive, and systems can go dark during the scramble. A PKI collapse is primarily a trust failure, and the operational cleanup after one is where the availability damage lands.
2. A botched migration. This is the more likely and more mundane one. Certificates that expire without being renewed, or systems left on algorithms that a partner has stopped trusting, reject connections, and a rejected connection is an outage. Post-quantum keys and signatures are also much larger than classical ones (the smallest ML-DSA signature runs over 2,400 bytes against roughly 64 for ECDSA P-256), so a migration can break size assumptions baked into parsers, buffers, and protocol limits, and a broken assumption surfaces as a failed handshake. NIST’s own guidance on certificate management flags unexpected certificate expiration as a leading cause of outages, and a large-scale algorithm migration multiplies exactly that failure mode.

The takeaway is a governance one rather than a cryptographic one. The migration has to be sequenced, inventoried, and tested precisely so that swapping algorithms doesn’t take services down, which is why crypto-agility and a real inventory matter for operations as much as for security. Managing the migration cleanly is how you keep it from becoming an availability event.

Source: NIST FIPS 204, “Module-Lattice-Based Digital Signature Standard,” August 2024, FIPS 204.

Source: NIST, “Securing Web Transactions: TLS Server Certificate Management,” SP 1800-16, June 2020, SP 1800-16.

Migration availability risk	Mechanism	How it’s managed
Expired certificates	A renewal is missed during the churn, and connections start failing	Inventory, automated renewal, monitoring of expiry
Un-migrated endpoints	A partner disables a deprecated algorithm and handshakes break	Coordinated sequencing, hybrid transition, testing
Oversized keys and signatures	Larger ML-DSA material overruns a buffer or size limit	Testing against real parsers and transport limits before cutover
PKI collapse cleanup	Revoking and reissuing a broken CA disrupts systems under it	Migrating CA keys early, staged trust-anchor rollout

Common misconceptions

1. “Availability is a networking problem, not a security problem.” Availability is one of the three core security goals in FIPS 199, on equal footing with confidentiality and integrity. That’s exactly why ransomware and denial-of-service count as security incidents and not merely outages.
2. “Quantum computing breaks everything, so it threatens availability too.” The quantum threat is a public-key cryptography problem, and it comes for confidentiality and trust. Availability rests on redundancy and operations, which the quantum math doesn’t touch.
3. “Encryption keeps my systems available.” Encryption serves confidentiality. Availability is a job for redundancy, backups, denial-of-service defenses, and recovery planning, and a perfectly encrypted system can still be entirely offline.
4. “The post-quantum migration has nothing to do with uptime.” The threat doesn’t attack availability, but a sloppy migration can, through expired certificates, broken handshakes, and oversized keys. Running it cleanly is an availability responsibility.
5. “A backup means my data is available.” A backup you’ve never tested restoring is a hope, not a guarantee. Availability depends on recovery that actually works within your Recovery Time Objective, which is why tested restores matter more than the existence of a backup.
6. “High availability and security are separate goals that trade off.” Availability is part of security, not a competitor to it. Redundancy and recovery are security controls in the same catalog as encryption and access control.

Questions people ask

What does availability mean in the CIA triad? It means information and systems stay accessible and usable for authorized users whenever they need them, the “A” alongside confidentiality and integrity. FIPS 199 defines it as ensuring timely and reliable access to and use of information.

How is availability different from confidentiality and integrity? Confidentiality is about who can read your data, integrity is about who can change it, and availability is about whether you can reach and use it at all. A system can succeed at two and fail the third, and each needs different controls.

Does the quantum threat affect availability? Barely, and not directly. The quantum threat breaks public-key cryptography, which attacks confidentiality and the trust behind authentication, while availability rests on redundancy and operations that quantum computers don’t threaten. The only real link is that a badly run migration can cause outages.

Then why does availability come up in a post-quantum guide at all? Because the migration touches it as a second-order risk. Expired or un-migrated certificates, broken handshakes from oversized post-quantum keys, and the cleanup after a PKI collapse can all take systems offline, so the transition has to be run carefully to protect uptime.

How do you protect availability? Through architecture and operations: redundancy and tested backups, denial-of-service mitigation and capacity planning, and rehearsed incident response and recovery. NIST SP 800-53 organizes these into control families like Contingency Planning and Denial-of-Service Protection.

Is ransomware an availability attack? Yes, primarily. Ransomware takes away your access to your own data and systems, which is a direct hit on availability, and it’s the main reason availability became a front-line security concern rather than a reliability footnote.

What are the “nines” in availability? They’re a shorthand for uptime percentage. “Three nines” is 99.9 percent (roughly 8.8 hours of downtime a year), and “five nines” is 99.999 percent (about 5 minutes a year). Higher targets demand more redundancy and cost more to sustain.

Do I need to worry about availability when planning a PQC migration? Not as a target of the quantum threat, but yes as a byproduct of the project. Inventory your certificates, automate renewals, test post-quantum sizes against your real systems, and sequence the rollout so that swapping algorithms doesn’t drop connections.

---

Everything here is the map, given freely. When your team needs a post-quantum migration sequenced so that swapping algorithms protects uptime instead of threatening it, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.