Quantum Security for Cloud and Network Teams: A Practical Checklist for 2026

Quantum-safe security is no longer a research topic reserved for cryptographers and forward-looking governments. For cloud security and network security teams, it is now an enterprise planning problem with real operational consequences: certificate rotation, TLS migration, vendor assurance, segmentation design, and key management all need to be made quantum-safe without breaking production. The fastest path is not to “boil the ocean,” but to build a practical quantum-safe checklist that prioritises the systems most exposed to crypto-agility gaps, maps your certificate lifecycle, and aligns your vendors to a transition plan that security operations can actually run.

The urgency is driven by a simple reality highlighted in the 2026 quantum-safe cryptography landscape: the “harvest now, decrypt later” threat is already here, while NIST’s post-quantum cryptography standards are now driving migration roadmaps across enterprises and governments. That means the question is not whether you should prepare, but how quickly you can reduce risk across cloud platforms, network controls, certificates, and privileged data flows. If you need a broader view of the ecosystem, see our guide to secure and scalable access patterns for quantum cloud services and our overview of managing the quantum development lifecycle for teams operating in regulated environments.

Pro Tip: Treat quantum-safe transition as an operational resilience programme, not a cryptography swap. The winning teams inventory, prioritise, test, and automate before they replace.

1. What quantum-safe migration means for cloud and network teams

Why the risk is operational, not theoretical

Cryptographically relevant quantum computers do not need to exist today for your data to be at risk. Attackers can capture encrypted traffic now, store it, and decrypt it later if your current public-key controls depend on RSA or ECC. For cloud and network teams, this affects VPNs, API gateways, service mesh mTLS, device identity, certificate authorities, secure email, and any long-lived data that crosses trust boundaries. The practical takeaway is that high-value, long-retention data should be prioritised first, especially where network capture or cloud replication creates a long exposure window.

The other operational issue is dependency depth. In a modern enterprise, cryptography is not just a TLS library choice in one application; it is embedded in load balancers, container ingress, hardware security modules, zero-trust policies, bastion access, PKI automation, SIEM correlation, and managed SaaS integrations. This is why quantum readiness must be handled like a platform migration. For a useful framing on enterprise decision-making, compare the “operate versus orchestrate” model in our decision framework for managing software product lines; the same logic applies when choosing what to keep operationally managed and what to orchestrate through standardised control planes.

NIST standards changed the timeline

NIST’s finalisation of PQC standards in 2024 and subsequent algorithm additions in 2025 pushed quantum-safe planning into mainstream security architecture. The implication for 2026 is that “wait and see” is no longer defensible for enterprise teams with compliance obligations or long-lived sensitive data. Standards availability means procurement, architecture, and migration work can begin now, even if full fleet cutover will take years. Teams should expect hybrid deployments first, with classical and PQC algorithms running in parallel to reduce business risk.

For cloud and network operations, the critical mindset shift is that crypto refresh cycles are now tied to endpoint lifecycle, certificate expiration, vendor roadmaps, and application release trains. This creates a governance problem as much as a technical one. The best way to avoid rushed remediation later is to inventory where crypto is used and assign ownership by system, not by team silo. That is the basis of the checklist below.

What “good” looks like in 2026

A mature quantum-safe programme in 2026 should have four qualities: visibility, prioritisation, agility, and validation. Visibility means you know where RSA, ECDSA, and legacy key exchange are used. Prioritisation means you know which assets carry long-lived confidentiality value. Agility means you can update algorithms and certificate profiles without redeploying every service from scratch. Validation means you can test PQC readiness in lab, staging, and limited production paths without breaking interoperability.

That standard may sound demanding, but it is achievable if you treat quantum-safe transition like a sequence of engineering sprints rather than a large-scale rewrite. The same principles that improve reliability in other infrastructure programmes apply here; see our practical note on building a telemetry-to-decision pipeline to understand how actionable signals turn into operational decisions. Quantum-safe security teams need that same feedback loop between asset inventory, risk scoring, and rollout control.

2. Your 2026 quantum-safe checklist: the executive summary

The checklist in one view

Use the following checklist as the minimum viable programme for cloud security and network security teams. It is designed to identify the systems that matter most, reduce the chance of a failed migration, and create a defensible path to board-level reporting. The list is intentionally operational: every item should map to an owner, a due date, and a test outcome. If you cannot measure the control, you do not yet have the control.

This table is the start, not the finish. The most successful teams will also align with change management, training, and vendor governance. If you are building the people side of the programme, our guide to skilling and change management for AI adoption translates well to quantum-safe initiatives because both require behavioural change, not just tool adoption.

Checklist priorities by business risk

Start with data that has a long retention period, is heavily replicated, or is exposed through externally reachable services. In cloud environments, that usually includes internet-facing APIs, identity providers, partner gateways, and service-to-service traffic that traverses shared networks. In enterprise networks, it also includes administrative channels, remote access, branch connectivity, and any MPLS or overlay service where the provider controls part of the trust chain. Quantum-safe transition should never begin with low-value internal traffic if the business owns archival, regulated, or strategic data elsewhere.

Then rank your controls by upgrade cost and failure risk. Certificates are usually quicker to modernise than deep application cryptography, but they can break if your tooling assumes fixed key lengths or specific signature formats. Network segmentation changes often create fewer cryptographic issues but higher business disruption, so they should be piloted carefully. Your checklist should therefore distinguish between “easy technical win,” “high-risk dependency,” and “must coordinate with vendor.”

Where to begin if you have no programme

If you are starting from zero, begin with a discovery sprint. Document every TLS termination point, every PKI issuer, every secret store, every HSM, and every externally managed connection that handles authentication or encryption. Tie each item to an owner and an expiry window, then produce a heat map that shows which systems are internet-facing, which are regulated, and which retain data for more than 12 months. That inventory becomes the foundation for both budget justification and migration sequencing.

Teams often ask whether they should wait for “full PQC support” before acting. The answer is no. Hybrid configurations and pilot zones are the right place to start, because they let you verify compatibility while preserving existing protections. This incremental approach is consistent with the broader quantum-safe market, where consultancies, cloud providers, PQC vendors, and QKD specialists are all offering partial solutions with varying maturity. Understanding those categories can help you decide whether a vendor is ready for production or only for proof-of-concept work; our article on the quantum-safe cryptography landscape is a useful orientation point.

3. TLS migration: the first control most teams must modernise

Map every TLS termination point

TLS is the most visible and usually the most underestimated part of the migration. A cloud environment may have TLS termination at CDN edges, WAFs, ingress controllers, reverse proxies, service meshes, API gateways, load balancers, application servers, and even internal sidecars. Network teams often own some of these components while platform teams own others, which is why ownership drift becomes dangerous. Your first task is to map where certificates are presented, where key exchange occurs, and where session resumption or mutual TLS is enforced.

Once you have that map, identify the versions and cipher suites in use. Legacy assumptions about RSA key exchange, ECDHE defaults, and certificate signature formats will influence whether PQC adoption can be handled through configuration or needs vendor upgrades. This is especially important in environments with older middleboxes or appliances that inspect traffic and may not tolerate larger handshake sizes. Build a compatibility matrix before any change window.

Adopt hybrid TLS patterns first

In 2026, most enterprises should plan for hybrid TLS rather than abrupt replacement. Hybrid approaches combine classical and post-quantum algorithms so that you preserve interoperability while gaining quantum resistance where supported. This is particularly helpful for external services, partner integrations, and service mesh migrations where both sides do not move at the same pace. Hybrid deployments also reduce commercial risk because they let you negotiate support expectations with vendors before full cutover.

That said, hybrid is not a permanent excuse for inaction. It is a transition state, and every hybrid deployment should have a planned exit criteria: a target service class, a cutover date, and a validation method. This is the same logic used in broader cloud transformation programmes, where the migration path matters as much as the destination. For teams evaluating access controls and rollout patterns, our guide to access patterns for quantum cloud services offers useful design ideas.

Test handshake size, latency, and device compatibility

PQC signatures and key encapsulation mechanisms can change handshake sizes and CPU characteristics. That matters in distributed systems with tight latency budgets, high connection churn, or constrained devices. Even if your primary cloud workload is comfortable with the extra overhead, your branch firewalls, VPN concentrators, or edge appliances may not be. Test at scale, not just in a lab, and include mobile clients, IoT endpoints, and legacy operating systems if they participate in your trust model.

Operationally, this means measuring handshake failure rates, CPU spikes, memory use, and certificate verification time. It also means checking how logs, packet capture tools, and observability platforms interpret new certificate chains. Quantum-safe migration should not be judged only on cryptographic soundness; it must also prove that the operational envelope stays within acceptable bounds. This is where security operations and network engineering need to work from the same dashboard and the same change calendar.

4. Certificate lifecycle: where migration projects succeed or fail

Inventory every certificate issuer and use case

Certificate lifecycle management is often where hidden complexity emerges. Enterprises may have internal CAs, cloud-managed certificate services, public trust certificates, automation tools, device certificates, code-signing certs, mTLS identities, and short-lived operational certificates all running simultaneously. A quantum-safe transition must identify which of these are externally trusted, which are internal only, and which have long-term trust dependencies. Without that segmentation, you risk replacing the wrong certificates first while leaving the most sensitive paths exposed.

Build an issuer map that includes issuance method, validity period, revocation process, renewal automation, and dependent applications. Then classify certificates by blast radius: administrative access, customer-facing traffic, machine identity, partner integration, and archival trust. This classification gives you a simple but powerful prioritisation tool for planning the transition sequence. If the certificate protects a root of trust or a high-value identity plane, it belongs near the top of the migration queue.

Shorten lifetimes where automation is mature

One of the most effective ways to improve resilience during crypto transition is to shorten certificate lifetimes where automation is reliable. Short-lived certificates reduce exposure and make rollbacks safer because you can rotate quickly if a hybrid handshake fails. This is especially valuable in cloud-native environments where infrastructure is ephemeral and service discovery is automated. The goal is not to churn certificates blindly, but to use short lifetimes as part of a controlled lifecycle strategy.

However, shortening lifetimes without automation can become a self-inflicted outage. If renewal processes depend on manual approvals or brittle scripts, the certificate estate becomes an operational hazard. Teams should therefore audit their certificate authority tooling, renewal hooks, monitoring, and break-glass procedures before changing validity periods. A strong lifecycle is built on automation, alerts, and clear ownership, not on hope.

Align certificate policy with quantum-safe transition

Your certificate policy should specify which algorithms are approved, which are deprecated, and which are permitted only for legacy interop. It should also define how hybrid certificates will be introduced, tested, and retired. In many enterprises, the policy becomes the enforcement point that prevents shadow IT from reintroducing weak controls. This is where the certificate lifecycle stops being an admin task and becomes a governance layer.

In practice, good policy also helps procurement and vendor management. If a supplier cannot meet your certificate requirements, they should not be allowed to keep a critical integration indefinitely. Treat certificate policy as a contract artifact, not just a technical standard. Teams that need help deciding what to enforce first may benefit from our procurement-oriented guide on enterprise procurement checklists, which applies the same disciplined thinking to evaluating vendor claims.

5. Key management: the hidden foundation of quantum-safe readiness

Classify keys by lifespan and exposure

Key management is the less visible but more fundamental part of the checklist. Every key should be classified by how long it must remain secret, where it is stored, how often it rotates, and which systems can access it. Long-lived encryption keys, signing keys, backup keys, and root keys deserve immediate attention because their compromise has outsized consequences. Quantum risk turns that importance up further: a key that is safe today but expected to protect archived records for ten years is already a migration candidate.

Cloud teams should map keys across KMS, HSM, secrets managers, application configs, CI/CD systems, and SaaS connectors. Network teams should include VPN credentials, device identity keys, RADIUS/TACACS integrations, and interconnect tokens. If the key can authenticate or decrypt sensitive data after a future quantum breakthrough, it should be on a remediation path now. The key idea is not to replace everything at once, but to eliminate the longest-lived and highest-value secrets first.

Use layered controls, not just stronger algorithms

Quantum-safe key management is not only about the algorithm used in the key exchange. It is also about key escrow boundaries, access control, audit trails, hardware protection, and lifecycle enforcement. If a key is stored in plaintext in a build pipeline, swapping RSA for PQC will not fix the real problem. Security teams should therefore review whether keys are protected by HSMs, whether access is role-based, whether break-glass access is logged, and whether exports are even permitted.

Where feasible, move toward envelope encryption and per-service keys with clear ownership. That reduces the blast radius if a single key is exposed and makes rotation easier. It also supports gradual transition because individual services can adopt new cryptographic primitives without forcing a global redesign. For teams building observability around key operations, our telemetry guide can help connect events to decisions in a measurable way.

Plan for crypto-agility in your key services

Crypto-agility means your systems can switch algorithms, key sizes, and certificate profiles with minimum downtime. In the real world, that requires abstraction layers in libraries, configuration-driven policy, and test coverage for edge cases. The objective is to make future migrations less painful than the current one. If your key services hard-code algorithm choices, your next migration will be just as disruptive as the current one.

Build migration-ready interfaces now: separate business logic from cryptographic implementation, centralise crypto configuration, and ensure your CI/CD pipeline can run compatibility tests against new providers. This is one of the best investments you can make for enterprise security because it turns future transitions into controlled change rather than emergency work. It is also the core of long-term PQC readiness.

6. Network segmentation and trust boundaries in a quantum-safe world

Segment by sensitivity, not just topology

Network segmentation is often discussed in terms of VLANs, subnets, or firewalls, but quantum-safe planning demands a sensitivity-first approach. A finance database, privileged admin plane, secrets vault, and partner API gateway should not be treated as equivalent simply because they live in the same cloud region. The goal is to reduce the amount of traffic that any single compromise can expose, especially traffic that has long retention value. If an attacker can record data from one flat segment and decrypt it later, the boundary was not meaningful enough.

Reassess east-west traffic, not just north-south ingress. Service-to-service communication often carries the most valuable data because it includes tokens, identifiers, and internal business context. That makes service mesh policy, micro-segmentation, and identity-aware access critical. Quantum-safe migration is an opportunity to reduce reliance on broad network trust and move toward explicit, least-privilege connectivity.

Protect admin planes and control planes first

Administrative interfaces are a high-priority target because they often provide escalation paths into production. That includes hypervisor consoles, Kubernetes APIs, cloud management portals, backup consoles, and remote access gateways. If these planes use long-lived credentials or legacy TLS settings, they create outsized risk. Replacing those trust paths early gives you the highest security return on effort.

In network terms, this means isolating management networks, enforcing MFA, tightening conditional access, and ensuring that control-plane certificates are on a short, audited lifecycle. It also means monitoring for unusual certificate issuance or unexpected TLS versions on privileged paths. Security operations should be able to answer, in minutes, which control-plane assets have not yet been validated for hybrid or PQC compatibility.

Consider blast radius and rollback plans

Segmentation projects often fail when they do not include rollback, testing, and change communication. The same is true here. Before introducing new trust boundaries or cryptographic dependencies, model what happens if a service fails, a certificate expires, or a vendor cannot negotiate a hybrid connection. Your rollback plan should include DNS, routing, firewall rules, and certificate fallback procedures.

Good segmentation is a defensive investment, but it also makes migration safer because it localises failures. If one zone is being tested with hybrid TLS, the rest of the estate can continue operating under existing rules while monitoring captures anomalies. That enables phased adoption instead of big-bang cutovers, which is usually the only realistic way to manage large enterprise estates.

7. Vendor readiness: what to ask before you sign or renew

Demand evidence, not marketing

Vendor readiness is one of the most important parts of the 2026 checklist because enterprises rarely control every cryptographic dependency themselves. Cloud providers, network hardware vendors, SaaS platforms, MSPs, and identity suppliers all influence your path to quantum-safe transition. Don’t accept generic “we are PQC-aware” statements. Ask for concrete evidence: roadmap dates, supported algorithms, interoperability test results, certificate handling details, and rollback guidance.

A strong vendor response should explain how they handle hybrid handshakes, what part of the stack they control, and whether any features remain in preview or limited availability. They should also identify how PQC support affects SLAs, performance, logging, and compliance. If they cannot provide this, they may still be suitable for non-critical workloads, but they should not anchor your most sensitive trust paths. To evaluate maturity across the broader market, the landscape overview from Quantum-Safe Cryptography: Companies and Players Across the Landscape is a useful reference point.

Ask about certificate and key portability

Vendor lock-in becomes a real issue when certificates and keys cannot be moved, rotated, or reissued cleanly. Before renewing a contract, ask whether the vendor supports exportable metadata, API-based renewal, programmable trust policies, and external CA integration. If the answer is no, you may be locking yourself into a migration path that is harder and more expensive later. This is especially painful in multi-cloud environments where certificate management already spans multiple control planes.

Also ask how the vendor records algorithm changes and whether those changes are visible in audit logs and SIEM integrations. Security operations needs to know when a vendor flips from classical to hybrid, when a certificate chain is renewed, and whether there is any change to trust anchors. The more transparent the vendor is, the easier it is to monitor the migration and meet compliance obligations.

Negotiate transition clauses

For critical suppliers, build quantum-safe requirements into renewals, procurement templates, and risk reviews. That may include support milestones, notification windows for crypto changes, and commitments to provide test environments. If you are working in a regulated industry, these clauses can become evidence of due diligence. They also reduce the chance that you discover a compatibility issue during an emergency patch cycle.

Where possible, require suppliers to publish their PQC roadmap, support timelines, and any dependencies on hardware refreshes. Some vendors will move quickly; others will lag. That difference should feed directly into risk scoring and contract prioritisation. Procurement is not separate from security architecture here — it is part of the controls framework.

8. Security operations: how to run quantum-safe controls day to day

Update detections and baselines

Security operations teams need fresh baselines to detect crypto drift, unexpected certificate changes, and protocol downgrades. That includes alerts for new TLS versions, weak cipher fallback, expired certificates, unusual CA issuers, and unplanned key rotations. In a hybrid transition, your monitoring should distinguish between approved dual-stack behaviour and suspicious negotiation patterns. Otherwise, the SOC will drown in false positives or miss a real incident.

Observability should also include operational metrics such as handshake failure rate, CA issuance volume, renewal success rate, and certificate age distribution. These are useful because they reveal whether the rollout is healthy before users complain. If your security tooling can already ingest configuration and telemetry data, pair it with a decision pipeline model similar to the one described in From Data to Intelligence. That mindset helps convert crypto status into actionable risk management.

Refresh incident response playbooks

Incident response procedures must change to reflect the new failure modes introduced by PQC and hybrid cryptography. Your team should know how to respond if a vendor handshake fails, a certificate chain becomes incompatible, a service mesh cannot negotiate a new algorithm, or a CA emits an unexpected profile. Playbooks should include isolation steps, fallback paths, escalation contacts, and communication templates for business stakeholders.

It is also worth simulating “crypto outage” scenarios in tabletop exercises. These are especially valuable for network teams, because a secure-by-design change can still trigger availability issues if dependencies were overlooked. The best drills include the SOC, service owners, PKI administrators, and vendor support representatives, since real-world failures often cross those boundaries.

Train analysts on quantum-safe signals

Analysts do not need to become cryptographers, but they do need to recognise the indicators of quantum-safe transition. That includes odd certificate renewal patterns, hybrid connection logs, misconfigured algorithm negotiation, and vendor changes that alter trust anchors. Training should focus on “what normal looks like” before and after migration phases, so analysts can distinguish expected change from malicious activity. This is one of the easiest ways to reduce alert fatigue during a complex programme.

For organisations building structured upskilling programmes, our article on skilling and change management is a useful template for designing practical learning pathways. The lesson is simple: if the team cannot explain the transition, they cannot safely operate it.

9. A practical 2026 rollout plan for enterprise teams

Phase 1: discover and classify

The first phase is all about inventory and prioritisation. Map TLS, certificates, keys, and vendor dependencies, then score each asset by data sensitivity, exposure, and retention period. Create a list of “must-migrate-first” services: internet-facing systems, admin planes, regulated data stores, partner gateways, and long-lived archives. At the same time, identify the vendors and platforms that can already support hybrid testing.

Deliverables for phase 1 should include a system register, a dependency map, a certificate catalogue, and a risk-based roadmap. These artefacts are valuable because they turn abstract quantum risk into a concrete programme that can be funded and tracked. They also make governance easier by giving leadership one source of truth rather than scattered project updates.

Phase 2: pilot and validate

Phase 2 should be limited, deliberate, and measurable. Choose a small number of services with high importance but manageable blast radius, then test hybrid TLS, certificate renewal, and security monitoring in controlled environments. Include rollback drills and compatibility checks for client versions, proxy layers, and logging tools. If the pilot fails, the failure is useful: it tells you what assumptions are unsafe before the migration becomes larger.

During pilot, make sure the SOC receives baseline data and that service owners know what success looks like. Validation should include not just “does it connect?” but also “does it remain observable, supportable, and compliant?” A pilot that works technically but breaks operations is not ready for production.

Phase 3: scale by control plane, not by chaos

When you scale, do it by control plane. Move certificate services, identity paths, high-value APIs, and management networks in a planned sequence. Avoid random workload-by-workload change waves because they make troubleshooting impossible. The goal is to create repeatable rollout patterns that platform teams can reuse.

As the programme matures, add vendor clauses, compliance evidence, and automated reporting. That will allow leadership to see progress without demanding manual updates from technical teams. It also makes quantum-safe readiness part of standard security governance rather than a one-off initiative that fades after the first milestone.

10. The 2026 quantum-safe checklist: copy this into your programme

Technical controls

1) Inventory all TLS termination points, certificate authorities, HSMs, and key stores. 2) Identify long-lived and externally exposed keys first. 3) Enable hybrid testing where supported. 4) Shorten certificate lifetimes only where automation is mature. 5) Verify handshake performance across cloud, branch, mobile, and partner paths. 6) Update monitoring for crypto drift and certificate anomalies.

Operational controls

7) Assign an owner for every cryptographic dependency. 8) Create rollback plans for TLS, routing, and PKI changes. 9) Add incident response playbooks for hybrid negotiation failures. 10) Train SOC analysts on new alert patterns. 11) Schedule tabletop exercises for control-plane and vendor failure scenarios. 12) Maintain a change calendar tied to renewal windows and release trains.

Governance and vendor controls

13) Require vendor PQC roadmaps and test evidence. 14) Include certificate portability and algorithm change reporting in contracts. 15) Prioritise suppliers that support external CA integration and auditability. 16) Report progress using risk reduction, not just project completion. 17) Review the programme quarterly against NIST-aligned standards and business retention needs. 18) Keep a living register of services not yet ready for migration.

Pro Tip: If you can’t answer “Which certificates will expire in the next 90 days, and which of those protect long-lived sensitive data?” you’re not ready to scale quantum-safe operations.

11. How to explain the business case to leadership

Frame it as risk reduction and continuity

Leadership usually does not need a lecture on elliptic curves; it needs clarity on business exposure, compliance, and resilience. Explain that quantum-safe migration reduces the risk of future decryption of archived data, protects trust anchors, and lowers the chance of a high-impact emergency retrofit later. Make the case that proactive migration is less expensive and less disruptive than a rushed response under regulatory pressure. That framing is especially effective when paired with timeline evidence from the broader market and standards community.

It is also useful to show that this work strengthens general security maturity. Better certificate hygiene, tighter key management, stronger segmentation, and cleaner vendor governance all reduce current-day risk, not just future quantum risk. In other words, this is a “now and next” investment, not a speculative one.

Show measurable milestones

Executives need visible milestones: percentage of certificate estates inventoried, number of vendors with PQC roadmaps, number of services validated in hybrid mode, and number of control planes with updated monitoring. These metrics help avoid vague progress reports. They also create accountability for the teams responsible for rollout.

Use quarterly reporting to show whether the organisation is moving from discovery to pilot to scale. If you can show a downward trend in unknown dependencies and a rising rate of automated renewals, you are demonstrating genuine control improvement. That is the language leadership understands.

Connect to procurement and resilience strategy

Finally, tie the programme to long-term supplier strategy and operational resilience. If you need a broader view of how enterprise buyers should evaluate readiness and integration claims, the public companies and ecosystem map can help surface the different types of organisations involved, from platform vendors to consultancy partners. Use that to benchmark your suppliers and diversify risk where needed. Quantum-safe preparedness is strongest when it is part of your wider enterprise security and resilience plan, not an isolated technical initiative.

Frequently Asked Questions

Related Reading

• Quantum Readiness for IT Teams: A Practical Crypto-Agility Roadmap - A step-by-step plan for building agility into your crypto stack before the next migration wave.
• Managing the Quantum Development Lifecycle - Learn how environments, access control, and observability support secure quantum programmes.
• Secure and Scalable Access Patterns for Quantum Cloud Services - A practical guide to designing safer access for cloud-based quantum workloads.
• Quantum-Safe Cryptography Landscape - A market map of the vendors, consultancies, and platforms shaping quantum-safe migration.
• Public Companies List - Quantum Computing Report - A broader ecosystem view of public companies active in quantum computing and security.