Category: Cybersecurity

AI cyber risk is easy to exaggerate and easy to dismiss. A model that can answer security questions is not automatically a super-powered attacker. But a model that can plan, code, search documentation, and interact with tools may change the amount of skill needed to attempt some cyber tasks.

That is why cyber capability evaluations are becoming more important. The question is not whether an AI system sounds confident. It is what the system can actually do under controlled conditions, how reliably it does it, and which safeguards reduce the risk of misuse.

Capability Is Different From Hype

Cybersecurity is full of ambiguous language. A model may be described as able to find vulnerabilities, automate attacks, or assist defenders. Those phrases mean little unless the task is defined. Is the model reading a public vulnerability write-up, solving a lab exercise, generating a phishing email, or exploiting a real target?

Recent work by NIST’s Center for AI Standards and Innovation, or CAISI, has focused attention on empirical testing. In July 2026, NIST and the UK AI Security Institute published a preliminary cyber capability assessment of Kimi K3. The useful part is not any one model headline, but the method: structured tasks, observable performance, and careful interpretation.

This complements our earlier article on AI evaluation beyond benchmark scores. In cybersecurity, the gap between a benchmark and a real incident can be especially wide.

Cyber Ranges Give Evaluations a Safer Playground

A cyber range is a controlled environment that simulates systems, networks, vulnerabilities, and defensive tools. It lets evaluators test behavior without attacking real organizations. That matters because cyber capability testing can otherwise create legal, ethical, and safety problems.

In a range, researchers can define what the model can see, what tools it can use, whether it receives hints, and how success is measured. They can also compare human-only performance, AI-assisted performance, and different levels of guardrails.

Good ranges are not perfect reality. They simplify messy enterprise networks, user behavior, business constraints, and live defensive monitoring. But they are better than vague anecdotes. They make claims measurable and repeatable.

Tool Access Changes the Risk

A language model in a chat box is different from an agent connected to a browser, terminal, vulnerability scanner, code repository, or cloud account. Tool access can turn advice into action. It can also introduce new failure modes when the model misunderstands context or runs a command too broadly.

Evaluations should therefore separate reasoning from execution. A model that can explain a known vulnerability is not the same as a system that can chain reconnaissance, exploit selection, payload generation, credential handling, and persistence in an environment.

The same distinction appears in defensive use. AI may help summarize logs or triage alerts, but it should not automatically quarantine critical systems without controls. Our discussion of AI in critical infrastructure applies directly here: ownership, fallback, logging, and human authority all matter.

Defensive Benefits Need Evidence Too

Cyber AI is not only an attacker story. Models can help analysts search documentation, write detection rules, understand malware behavior, generate incident summaries, or map vulnerabilities to affected assets. Those uses can reduce workload when they are carefully integrated.

But defensive claims also need testing. Does the model miss important alerts? Does it hallucinate nonexistent indicators? Does it reveal sensitive logs to a third-party service? Does it produce scripts that look plausible but break production systems?

Organizations should measure time saved, false positives, false negatives, analyst trust, and error recovery. A tool that impresses in a demo may still fail under alert fatigue, incomplete logs, or incident pressure.

Guardrails Are Part of the System

Model behavior depends on prompts, policies, classifiers, tool permissions, rate limits, identity checks, logging, and review processes. A cyber capability evaluation that ignores those layers may overstate or understate real risk.

NIST’s CAISI work sits within a broader push to measure advanced AI capabilities and support standards. For cybersecurity, that means evaluating not just raw model responses, but how deployed systems behave when users ask for dual-use help.

Some information is useful to defenders and harmful to attackers. A blanket refusal may block legitimate security work, while a permissive system may enable misuse. The hard task is building controls that recognize context, user authorization, and operational boundaries.

What Organizations Can Do Now

Most companies do not need to build national-level AI cyber evaluations. They do need clear rules for AI use in security work. That starts with approved tools, data-handling limits, logging, and a ban on testing against systems without authorization.

Teams should also maintain conventional controls. AI does not replace patch management, identity security, network segmentation, incident response, or software inventory. The discipline in SBOM and vulnerability management still matters.

When buying AI-enabled security products, ask how the vendor evaluates cyber capability, misuse resistance, data privacy, model updates, and failure handling. A useful answer should include more than marketing language.

What to Watch Next

Watch for more public evaluations that describe tasks, environments, scoring, and limits. Also watch whether models are tested with tools, multiple attempts, and realistic defensive noise. Those details decide whether a result tells us anything useful.

The strongest future for AI in cybersecurity is evidence-driven. That means neither panic nor complacency. It means measuring what systems can do, restricting dangerous workflows, and using AI where it measurably helps defenders.

Sources and Further Reading

• NIST and UK AISI: preliminary assessment of Kimi K3’s cyber capabilities
• NIST: Center for AI Standards and Innovation
• CISA: Roadmap for Artificial Intelligence

The internet can appear to choose a direct path, but traffic actually crosses networks run by different companies, universities, governments, and cloud providers. Those networks use the Border Gateway Protocol, or BGP, to announce which internet addresses they can reach. The system is resilient and decentralized, but its original design does not authenticate every route announcement.

Resource Public Key Infrastructure, usually called RPKI, adds cryptographic evidence about which autonomous system is authorized to originate a block of addresses. It can stop a useful class of mistakes and hijacks. It is not, however, a complete security layer for BGP, and describing it that way can hide the controls operators still need.

Why BGP Trust Can Go Wrong

The global routing system connects autonomous systems, each identified by an autonomous system number. A network announces address prefixes to its neighbors, those neighbors select routes according to policy, and the information propagates. If an organization accidentally announces a prefix it does not operate, or an attacker deliberately advertises a false origin, other networks may accept the route.

Traffic can then be dropped, diverted, or sent along an unexpected path. The event may affect one narrow prefix or a widely used service. BGP’s distributed design makes rapid coordination possible, but it also means one faulty announcement can travel beyond the network that created it.

These incidents are different from the application attacks covered by memory-safe software development. A website can have secure code and encrypted connections while the network path used to reach it is still incorrectly announced.

RPKI Connects Address Space to an Authorized Origin

RPKI lets a holder of internet number resources create a Route Origin Authorization, or ROA. A ROA states that a particular autonomous system is authorized to originate a prefix and specifies the most-specific route length allowed. The authorization is signed through a certificate hierarchy tied to address-resource allocation.

Routers do not normally fetch and validate public-key objects while making every forwarding decision. Operators use RPKI validators to collect repository data, check the cryptographic chain, and present validated origin information to routing systems. This separation keeps heavy validation work away from the packet-forwarding path, but it makes validator availability and configuration operational concerns.

RFC 6483 describes three origin-validation outcomes. A route is valid when a matching authorization permits its origin and prefix length. It is invalid when covered resource data exists but the announcement conflicts with it. It is not found, often called unknown, when no covering authorization is available.

Route Origin Validation Turns Evidence Into Policy

Publishing a ROA does not automatically change how the rest of the internet routes traffic. Receiving networks must perform Route Origin Validation, or ROV, and apply a policy to the result. Many reject invalid announcements, prefer valid routes, or use validation state as one signal among several.

A cautious rollout matters. A legitimate route can become invalid because its owner entered the wrong origin number, set an overly restrictive maximum prefix length, or changed providers without updating the authorization. Monitoring first, maintaining accurate ROAs, and coordinating changes can prevent a security control from causing an avoidable outage.

NIST’s draft revision of Special Publication 800-189 discusses RPKI, ROAs, ROV, prefix filtering, and complementary BGP security practices. Its layered treatment is important: validation is a process involving resource holders, transit providers, route collectors, and operational response, not a box that one organization checks alone.

What RPKI Can Stop

ROV is well suited to an origin hijack in which the wrong autonomous system announces another organization’s prefix. If the resource holder has published a correct ROA and receiving networks enforce invalid-route policy, the false origin can be filtered before it attracts traffic.

It can also catch common configuration mistakes. A provider announcing a customer’s address space from an unauthorized origin, or announcing a more-specific prefix longer than the authorized maximum, can produce an invalid state that monitoring systems flag quickly.

The protection grows as both sides participate. Resource holders must create and maintain authorizations, while networks that receive routes must validate and use the result. An accurate ROA still provides useful visibility when deployment is incomplete, but it cannot force every remote network to reject an invalid announcement.

What RPKI Does Not Prove

Origin validation answers a narrow question: is the final autonomous system authorized to originate this prefix? It does not prove that the complete AS path is legitimate. A route leak can retain a valid origin while carrying an implausible or unauthorized path through other networks. An attacker may also construct an announcement that ends at the authorized origin but manipulates earlier path information.

RPKI also does not replace prefix filters, maximum-prefix limits, peer policy, route monitoring, incident contacts, or secure router administration. Repository outages and stale data need defined fail-safe behavior. Operators should test how validators, routers, and policy respond before treating validation state as a hard dependency.

This layered approach resembles zero-trust security: one verified attribute can narrow risk without making every surrounding component trustworthy. It also benefits from the inventory discipline discussed in software bill of materials programs. Organizations cannot maintain route authorizations well if ownership, providers, prefixes, and responsible teams are unclear.

Policy Attention Is Increasing

Governments are paying closer attention because routing failures can affect communications and critical services beyond one operator. In 2024, the US Federal Communications Commission issued a Notice of Proposed Rulemaking that discussed BGP security risk-management plans and reporting on ROA coverage for certain providers.

That document was a proposal, not a blanket final mandate for every internet network. The distinction matters. Operators should follow current regulatory decisions and contractual requirements instead of treating an earlier proposal as settled law.

A Practical Deployment Sequence

• Inventory every prefix, origin autonomous system, transit relationship, and responsible owner.
• Create accurate ROAs with deliberate maximum lengths and a documented change process.
• Run redundant validators, monitor repository freshness, and compare results before enforcement.
• Observe invalid routes, investigate legitimate exceptions, and then apply policy in stages.
• Retain prefix filters, peer limits, route monitoring, incident contacts, and configuration controls.

Measurements should distinguish ROA coverage from ROV enforcement. A network may authorize all its own routes yet accept invalid routes from peers, or enforce validation while its own address space remains partly undocumented. Both sides are necessary for meaningful ecosystem protection.

What to Watch Next

Watch the share of announced address space covered by valid ROAs, the number of major networks rejecting invalid routes, and progress on mechanisms that validate more than the origin. Also watch operational quality: inaccurate authorizations can undermine confidence even when deployment statistics rise.

RPKI is valuable precisely because it solves a defined problem. It can make false route origins much harder to propagate, but internet routing will remain a layered trust system. The strongest outcome is accurate origin authorization combined with path-aware monitoring, careful peering policy, and operators prepared to respond when the global view changes.

Sources and Further Reading

• NIST: Resilient Interdomain Traffic Exchange, draft SP 800-189 Rev. 1
• NIST: Protecting the Integrity of Internet Routing
• IETF RFC 6483: Validation of Route Origination Using RPKI
• FCC: 2024 BGP Security Notice of Proposed Rulemaking

A software bill of materials, or SBOM, is often described as an ingredient list for software. That analogy is useful as long as nobody mistakes the list for a safety certificate. An SBOM can identify packages, versions, suppliers, and relationships inside a product. It does not prove that those components are free of vulnerabilities, correctly configured, reachable by attackers, or maintained over time.

The security value appears only when an organization can connect an SBOM to the software it actually runs, evaluate new vulnerability information, contact the responsible supplier, and take action. In other words, an SBOM is structured inventory data. Vulnerability management is the operational system built around it.

What an SBOM Is Supposed to Contain

The U.S. National Telecommunications and Information Administration described minimum elements covering data fields, automation support, and practices and processes. Core fields include the supplier and component names, component version, unique identifiers, dependency relationships, the SBOM author, and a timestamp.

Common machine-readable formats include SPDX and CycloneDX. Automation matters because modern products can contain hundreds or thousands of direct and transitive dependencies. A document that cannot be reliably parsed, compared, and updated will age faster than the software it describes.

Relationships are especially important. A top-level application may depend on a library that depends on another package several layers down. A flat list can reveal presence, but a dependency graph helps responders understand where a component came from and which product versions may be affected.

Inventory Is Not Evidence of Exploitability

Matching a component name and version to a vulnerability database can produce a useful lead. It can also produce false positives and false confidence. The vulnerable code path may not be compiled, enabled, or reachable in the product. Conversely, an imprecise package name, modified component, or missing transitive dependency can hide a real exposure.

Security teams therefore need context. A supplier may provide a Vulnerability Exploitability eXchange, or VEX, statement explaining whether a known vulnerability affects a product and why. That claim should be specific, current, and supported by analysis. It should not become a generic “not affected” stamp that ends investigation.

The same principle applies to our discussion of the EU Cyber Resilience Act: finding, assessing, fixing, and communicating vulnerabilities are connected lifecycle activities. A component list supports them, but does not perform them.

The SBOM Must Match a Real Artifact

An organization should be able to tell which exact release, build, container image, firmware package, or installed product an SBOM describes. If a supplier posts one generic list for an entire product family, responders may not know whether it matches the version in front of them.

Integrity and origin also matter. CISA’s guidance recommends checking whether an SBOM came from the expected source and whether it was altered. Digital signatures, authenticated repositories, and hashes can help bind the inventory to a supplier and software artifact. The controls have to include the keys and repository, not only the file.

Build-generated SBOMs can be closer to the final artifact than a manually maintained spreadsheet. Even then, tools may see different dependency layers. Source manifests, package-manager locks, compiled binaries, container layers, vendored code, and runtime plugins can each reveal something different. Mature programs compare these views instead of declaring one scanner complete.

Completeness Is a Measured Property

“Has an SBOM” is too weak a procurement question. Buyers should ask which software layers it covers, what tool or process generated it, how often it changes, and how omissions are handled. They should also test whether identifiers are precise enough for automated matching.

A useful quality review samples known components from the artifact and checks whether they appear in the SBOM. It also samples listed components and checks whether they can be traced to the artifact or build. This does not prove perfect coverage, but it can expose systematic gaps such as missing operating-system packages or bundled JavaScript.

Memory safety illustrates why presence alone is not a risk rating. A product may list components written in several languages, but teams still need to understand exposed interfaces and mitigation. Our guide to memory-safe software covers that engineering layer.

Connect SBOMs to Asset Management

An SBOM for a product that nobody can locate is of limited use during an incident. Organizations need to map product versions to devices, servers, cloud workloads, and owners. That is often harder than collecting the supplier’s file.

A practical workflow ingests the SBOM into an inventory or security platform, normalizes identifiers, links it to deployed assets, and watches trusted vulnerability sources. When a credible alert appears, the team can identify candidate systems, ask suppliers for status, test reachability, prioritize exposure, and track remediation.

This workflow should account for software that changes at runtime. Plugins, downloaded models, browser extensions, and dynamically installed packages can make a release-time inventory incomplete. High-risk systems may need recurring discovery in addition to supplier SBOMs.

Prioritization Needs More Than a Severity Score

A high vulnerability score does not automatically identify the most urgent system. Responders also consider known exploitation, internet exposure, privileges, data sensitivity, business impact, available mitigations, and the confidence of the component match. A lower-scored issue on an exposed gateway may deserve action before a theoretical flaw in unreachable code.

That does not justify ignoring difficult patches indefinitely. It means the SBOM should feed a risk decision with a recorded rationale. Teams can then revisit the decision when exploit information, product configuration, or supplier guidance changes.

Suppliers Need a Maintenance Promise

An SBOM begins losing value as soon as software changes. Contracts and procurement programs should define when suppliers provide updates, how long products receive security support, how customers receive vulnerability notices, and what happens when a component reaches end of life.

Organizations should also know whether the supplier can regenerate the SBOM after an emergency patch. A one-time document prepared for a sale does little for a product deployed for ten years. This is particularly important for embedded and operational technology that cannot be replaced as quickly as a web service.

A Practical Starting Point for Smaller Teams

A small organization does not need to build a giant data platform before using SBOMs. It can start with a narrow, repeatable process:

1. Choose the most exposed or business-critical products.
2. Ask suppliers for machine-readable SBOMs tied to exact versions.
3. Store them with purchase, owner, support, and deployment records.
4. Test a few component and vulnerability queries before an emergency.
5. Document who contacts the supplier and who decides on mitigation.
6. Repeat the process after major upgrades and security fixes.

This complements basic controls such as patching, access restriction, backups, logging, and segmentation. It does not replace the broader discipline described in our zero-trust security guide.

Limits and Sensitive Information

Detailed component information can help defenders, customers, and researchers. Suppliers may also worry that it reveals product architecture. Access policies can vary with sensitivity, but secrecy should not be used to conceal unsupported dependencies or prevent legitimate security work.

An SBOM also cannot describe every relevant weakness. Logic errors, insecure defaults, leaked credentials, malicious build steps, cloud misconfiguration, and flaws in custom code may not appear as vulnerable third-party components. Secure development and testing remain necessary.

What to Watch Next

Watch for better identifier quality, signed attestations that connect SBOMs to builds, improved VEX interoperability, and procurement rules that measure freshness and coverage instead of accepting any file named “SBOM.” Also watch how product-security regulation turns inventory into ongoing supplier obligations.

The useful question is not “Do we have an SBOM?” It is “Can we use this inventory to find the affected systems and make a defensible decision while an incident is unfolding?” That is the point where structured data becomes security capability.

Sources and Further Reading

• CISA: Software Bill of Materials resources
• CISA and Enduring Security Framework: Recommended practices for SBOM consumption
• NTIA: Minimum elements for a Software Bill of Materials
• NIST: Software supply chain security guidance

A connected product can remain in homes and businesses for years after its first sale. During that time, researchers discover vulnerabilities, attackers develop exploits, and the software components inside the device continue to change. Europe鈥檚 Cyber Resilience Act is intended to make cybersecurity a product-lifecycle responsibility rather than a feature that ends at launch.

The regulation鈥檚 main provisions become fully applicable in December 2027, but an important earlier deadline is approaching. From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting covered products with digital elements. The timetable will make vulnerability intake, triage, evidence, and communication operational requirements for companies that sell connected hardware or software in the European Union.

Which Products Are Covered?

The Cyber Resilience Act, or CRA, applies broadly to products with digital elements made available on the EU market when their intended or reasonably foreseeable use includes a direct or indirect data connection. That can include consumer devices, network equipment, business software, and software components. Some categories governed by other sector-specific EU rules are excluded or treated separately.

The main obligations generally fall on the manufacturer: the entity that develops a product, or has it developed, and markets it under its own name or trademark. Importers and distributors have their own checks and cooperation duties. The exact role matters because a product may be designed outside Europe, branded by another company, and sold through several channels.

Reporting Starts Before the Main Rules

The CRA entered into force in December 2024. Rules concerning conformity-assessment bodies started applying in June 2026. The vulnerability and incident reporting obligations apply from September 11, 2026, while the main product requirements apply from December 11, 2027.

The earlier reporting date matters because it covers products with digital elements already made available on the EU market, not only newly launched products. A manufacturer cannot wait for the 2027 product-compliance deadline before building a process for receiving security reports and deciding whether an event meets the notification criteria.

That process is different from a general customer-support queue. It needs people who can connect a report to affected product versions, reproduce the issue, determine exploitation status and impact, coordinate a corrective measure, and meet a short regulatory clock.

What Must Be Reported?

The reporting rules focus on actively exploited vulnerabilities and severe incidents that affect the security of the product. A vulnerability is not automatically reportable merely because it exists or has been disclosed. The exploitation and impact criteria matter, and manufacturers need documented methods for making those judgments.

The European Commission鈥檚 implementation page describes a staged timetable. An early warning is due within 24 hours after the manufacturer becomes aware. A main notification follows within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification.

One Platform Connects Multiple Authorities

Manufacturers will submit through the CRA Single Reporting Platform being established by the European Union Agency for Cybersecurity, ENISA. The notification is addressed to the Computer Security Incident Response Team, or CSIRT, in the member state where the manufacturer has its main establishment. Information is then shared with ENISA and relevant national CSIRTs under the regulation鈥檚 process.

The Commission says the platform will be operational by the September 2026 reporting date and will have a testing period before launch. Companies still need their own internal case system. The regulatory portal is the destination for a report, not a substitute for product inventories, on-call decisions, technical investigation, or customer communication.

ENISA鈥檚 European Vulnerability Database is related but separate. The CRA platform handles mandatory reports, including information about actively exploited vulnerabilities that may not yet be public. The EU vulnerability database is designed to make public vulnerability information accessible. Coordination between disclosure and remediation remains important so that a report does not unnecessarily give attackers a head start.

Software Inventories Become Operational Infrastructure

A manufacturer cannot respond quickly if it does not know which products contain a vulnerable library, service, or firmware component. A software bill of materials can help identify dependencies, but an inventory is useful only when it is current, connected to product versions, and paired with a way to assess whether the vulnerable code is reachable in a specific configuration.

Teams also need ownership information. A component may be maintained by an upstream open-source project, packaged by a supplier, integrated by a contractor, and shipped under the manufacturer鈥檚 brand. Contracts and incident plans should establish who investigates, who produces a fix, and who makes the regulatory decision.

The underlying implementation quality still matters. Moving security-critical code toward memory-safe languages can eliminate important classes of vulnerabilities, while code review, dependency control, testing, and secure update mechanisms address other failure modes. Reporting is the response layer, not the entire security program.

Support Periods Make Updates a Product Promise

The CRA鈥檚 broader requirements include effective vulnerability handling during the product鈥檚 support period and clear information for users. That pushes manufacturers to decide how long a connected product will receive security updates and to align hardware, software, suppliers, and update infrastructure around that period.

A long support statement has little value if an update cannot reach devices reliably or if installing it breaks essential functions. Products need authenticated updates, rollback or recovery where practical, version visibility, and a way to notify owners. Devices that are offline for long periods require special planning.

These concerns are visible in the smart-home security questions buyers should ask. Consumers benefit when update duration, reporting contacts, and end-of-support behavior are understandable before purchase rather than hidden in technical documentation.

Open Source Has a More Nuanced Role

Free and open-source software that is not supplied as part of a commercial activity is treated differently from a commercial product. The CRA also defines an open-source software steward: a legal entity that provides sustained support for particular open-source software intended for commercial activities and ensures its viability.

Stewards have duties involving cybersecurity policy, cooperation, corrective action, and reporting in the circumstances described by the regulation, but the framework is not identical to the obligations on a conventional product manufacturer. Companies that package open-source components into commercial products cannot assume the upstream project becomes responsible for the finished product.

What Good Preparation Looks Like

A workable program starts with a maintained list of products, software versions, components, support periods, and responsible teams. It provides a monitored channel for researchers and customers, a severity and exploitation triage method, protected evidence storage, and an escalation path that operates outside normal office hours.

Teams should rehearse the 24- and 72-hour timelines using a realistic scenario. The exercise can test who has authority to submit, which facts are available early, how legal and technical teams coordinate, and how communications avoid both delay and speculation. It should also test simultaneous remediation across several products that share one component.

Access to the reporting process should follow zero-trust principles. A platform account and sensitive vulnerability evidence should not be broadly shared. Strong identity, limited roles, logging, and recovery procedures reduce the chance that the response system itself becomes a target.

Limits and Unanswered Questions

Regulatory reporting does not guarantee that a fix arrives quickly, that users install it, or that every exploited vulnerability is detected. A short deadline may also produce incomplete early reports. The quality of later investigation, remediation, coordinated disclosure, and product updates remains decisive.

Implementation guidance and platform procedures will continue to mature. Manufacturers operating across several regimes may face overlapping incident definitions and reporting channels. Harmonized internal evidence can help, but each legal obligation still needs its own analysis.

What to Watch Next

Watch ENISA鈥檚 testing and launch of the Single Reporting Platform, Commission guidance on implementation, and how national CSIRTs coordinate submissions. Product makers should also watch the standards used to demonstrate conformity before the broader December 2027 requirements take effect.

For consumers, the most meaningful change will be quieter: clearer support periods, reachable security contacts, and products designed to receive fixes throughout their useful life. The reporting deadline is one visible milestone in a larger shift from optional device security toward accountable lifecycle engineering.

Sources and Further Reading

• European Commission: Cyber Resilience Act reporting obligations
• European Commission: Summary of the Cyber Resilience Act
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act
• ENISA: European Vulnerability Database and CRA reporting platform FAQ

Many serious software vulnerabilities begin with a simple problem: a program reads or writes memory that it should not touch. Buffer overflows, use-after-free errors, double frees, and uninitialized memory can crash a system or give an attacker a route to run code. Security agencies are now pushing software producers to prevent these defects at the programming-language level instead of relying only on testing and patches.

That shift is driving interest in memory-safe languages. These languages use built-in rules and runtime protections to restrict dangerous memory operations. They cannot make software perfectly secure, but they can remove a large class of mistakes before a product reaches users.

What Memory Safety Means

Programs continuously allocate memory, read data, change values, and release storage that is no longer needed. In a memory-unsafe environment, the developer has direct control over many of those operations. That control is valuable for low-level systems work, but a small error can make one part of a program overwrite another, keep using memory after it has been released, or expose data that should remain private.

A memory-safe language tries to make invalid access impossible or much harder. Different languages use different techniques. Managed languages may rely on automatic memory management and bounds checks. Rust uses ownership and lifetime rules that the compiler checks before the program runs. Other languages combine compile-time checks, runtime checks, and restricted escape hatches for operations that genuinely need direct access.

The result is not merely cleaner code. Preventing the underlying mistake can eliminate an entire route to exploitation. That is a different strategy from detecting a known attack pattern after a vulnerable product has already shipped.

Why Government Guidance Has Become More Direct

In June 2025, the US National Security Agency and the Cybersecurity and Infrastructure Security Agency released joint guidance on memory-safe languages in modern software development. The guidance describes language-level protection as a way to reduce vulnerabilities, improve reliability, and lower the risk of incidents. It also emphasizes that adoption does not require rewriting every existing line at once.

CISA and the FBI made the same principle concrete in a 2025 Secure by Design alert about buffer overflows. Their recommendations include using memory-safe languages where feasible, writing new components in safer languages, prioritizing exposed or highly privileged code, using compiler protections and sanitizers during transition, and publishing a phased memory-safety roadmap.

This approach fits the broader idea that vendors should reduce risk before transferring it to customers. It complements operational controls such as the identity checks and limited access described in our article on zero trust security. Zero trust can limit what compromised software reaches, but it does not repair the software defect that enabled compromise.

Migration Is Usually Incremental

A mature operating system, browser, industrial controller, or network service may contain millions of lines of code and decades of dependencies. Replacing the entire codebase would introduce cost, compatibility problems, and new defects. A practical roadmap starts by finding where memory risk is concentrated.

Teams can use vulnerability history, code ownership, attack surface, privileges, and exposure to identify priorities. A parser that processes untrusted network data may deserve attention before an isolated internal utility. New services and modules can be written in a memory-safe language. Existing components can be wrapped behind narrow interfaces, while especially risky functions are rewritten over time.

Interoperability is therefore central. A safer module often has to call an older C or C++ library, interact with a device driver, or share data through a foreign-function interface. The boundary must be reviewed carefully because language guarantees may stop at that point. A program written mostly in a memory-safe language can still inherit a vulnerability from an unsafe dependency.

What Memory-Safe Languages Do Not Solve

Memory safety is one security property, not a complete security model. A safe program can still contain weak authentication, authorization mistakes, insecure defaults, exposed secrets, flawed cryptography, injection vulnerabilities, or incorrect business logic. Developers can also misuse unsafe language features, disable checks, or introduce denial-of-service problems through excessive resource consumption.

Supply-chain security remains important as well. A memory-safe application may import packages that are malicious, abandoned, or incorrectly configured. Updates must be authenticated and delivered safely. Operators still need logging, incident response, backups, and carefully designed access controls.

Nor should buyers treat a language name as proof of product quality. The meaningful evidence is how the vendor uses the language, which components remain unsafe, how dependencies are managed, and whether the company publishes measurable progress. This is similar to the migration discipline required for post-quantum cryptography: inventory first, prioritize risk, test interoperability, and avoid a rushed replacement.

Performance and Hardware Constraints Still Matter

Some low-level systems have tight requirements for latency, memory use, binary size, certification, or hardware access. A language and toolchain that works well for a cloud service may not fit a tiny embedded controller. Teams must evaluate real workloads rather than assuming one language is ideal everywhere.

That does not make memory safety optional. When a full language transition is not currently feasible, agencies recommend layers of mitigation: compiler hardening, address-space protections, canaries, fuzzing, static analysis, runtime sanitizers, careful review, and architectural isolation. These controls reduce risk while the highest-value parts of the codebase move toward safer foundations.

What Buyers and Organizations Can Ask

Most consumers cannot inspect a product’s source code, but organizations buying critical software can ask useful questions. Does the vendor track memory-safety vulnerabilities separately? Are new exposed components written in memory-safe languages? Is there a published migration roadmap? Which unsafe libraries remain, and how are they isolated and tested? Does the vendor conduct root-cause analysis across a product line instead of patching one bug at a time?

For connected devices, support duration also matters. A product with safer code can still become risky if updates stop. Our smart home security checklist explains why update policy, account protection, and network design should be evaluated together.

What to Watch Next

Progress will be visible in procurement requirements, secure-development attestations, open-source dependency plans, and published measurements of vulnerability classes. Watch whether vendors disclose which high-risk components have moved, whether major libraries offer stable safe interfaces, and whether toolchains make mixed-language analysis easier.

The important change is cultural as much as technical. Security teams are asking producers to eliminate predictable defect classes during design, not celebrate faster patching after exploitation. Memory-safe languages are not a universal cure, but they are becoming a baseline expectation for software that society depends on.

Sources and Further Reading

• NSA and CISA: Memory-Safe Languages in Modern Software Development
• CISA and FBI: Eliminating Buffer Overflow Vulnerabilities
• CISA and International Partners: The Case for Memory-Safe Roadmaps

Smart home devices promise convenience: cameras, locks, thermostats, speakers, lights, sensors, and appliances that respond to apps or voice commands. They also add new security and privacy questions.

Why It Matters

A poorly secured device can expose video, location patterns, household routines, or account access. Consumers do not need to become security experts, but they should know what to check before buying and installing connected devices.

Where It Shows Up

Start with reputable brands, update support, strong account security, privacy controls, and network settings. Use unique passwords, enable multi-factor authentication, and consider separating smart devices from primary computers when possible.

What to Watch

• How long the manufacturer promises security updates
• Whether the device requires cloud access to function
• Privacy controls for recordings and voice data
• Compatibility with common smart home standards

A smart home should make life easier without quietly increasing risk. The best devices are useful, updated, transparent, and easy to control.

Category: Cybersecurity. This article is part of Frontier Technology Portal’s plain-English guide to the technologies shaping the next decade.

Zero trust is a security model built around a simple idea: do not automatically trust a user, device, or application just because it is inside a network. Verify access based on identity, device health, context, and least privilege.

Why It Matters

Work has moved across cloud services, remote devices, mobile apps, contractors, and personal networks. The old perimeter is weaker, so security has to follow the user and the data.

Where It Shows Up

A practical zero trust program may include multi-factor authentication, passkeys, device management, identity governance, network segmentation, access logs, conditional access, and regular permission reviews.

What to Watch

• Identity systems that are easy enough for employees to use
• Device posture checks before sensitive access
• Reduced standing privileges for administrators
• Monitoring that detects unusual behavior without overwhelming teams

Zero trust is not a single product. It is a direction: verify more carefully, grant less access by default, and assume compromise is possible.

Category: Cybersecurity. This article is part of Frontier Technology Portal’s plain-English guide to the technologies shaping the next decade.

Updated July 11, 2026, to include the latest NIST implementation work and US federal migration guidance.

Post-quantum cryptography has moved from a research project into an infrastructure upgrade. The goal is to replace vulnerable public-key algorithms with methods designed to resist attacks from both conventional computers and future cryptographically relevant quantum computers. Organizations do not need to wait for such a machine to exist before planning. Cryptographic migrations take years, and information stolen today may still be sensitive when more powerful systems arrive.

The practical task is not to buy a mysterious “quantum security” product. It is to discover where cryptography is used, adopt standardized algorithms through maintained software and hardware, test compatibility, and make future changes easier. In June 2026, new US federal directives accelerated that shift from preparation to execution.

What a Powerful Quantum Computer Could Break

Modern digital systems use different kinds of cryptography for different jobs. Symmetric algorithms such as AES protect the contents of data once two parties share a secret key. Public-key algorithms such as RSA and elliptic-curve cryptography help establish keys and create digital signatures without a pre-shared secret.

A sufficiently capable fault-tolerant quantum computer running Shor’s algorithm could undermine the mathematical problems that protect widely used RSA and elliptic-curve systems. That would affect key exchange, certificates, software signatures, device identities, secure email, virtual private networks, and many other protocols.

This does not mean every encrypted file becomes readable overnight. Symmetric cryptography is affected differently, and real attacks would depend on hardware scale, error correction, implementation, access, and target value. The reason to act early is that public-key cryptography is embedded deeply in long-lived systems.

The “Harvest Now, Decrypt Later” Risk

An attacker can collect encrypted traffic today even if it cannot yet break the protection. If the information remains valuable for many years, the attacker may store it and attempt decryption after technology improves. This threat is most relevant to long-lived government, research, health, industrial, and intellectual-property data.

Organizations should therefore compare two timelines: how long the data must stay confidential and how long migration will take. A system that stores sensitive information for 15 years cannot assume that a five-year transition starting later will be sufficient.

The First NIST Standards Are Ready

In August 2024, the National Institute of Standards and Technology finalized three post-quantum standards:

• FIPS 203, ML-KEM: a key-encapsulation mechanism used to establish shared secret material.
• FIPS 204, ML-DSA: the primary lattice-based standard for digital signatures.
• FIPS 205, SLH-DSA: a hash-based signature standard designed as an alternative with a different mathematical foundation.

A key-encapsulation mechanism is not the same as a general-purpose file encryption algorithm. It helps two systems establish a shared secret, which can then be used with symmetric encryption. A digital signature protects authenticity and integrity: it helps a recipient verify who signed software, a document, or a protocol message and whether it was changed.

Standardization is only the beginning. Products need correct implementations, protocol updates, performance testing, secure key storage, certification, and compatibility across vendors.

Why 2026 Is a Migration Year

In June 2026, NIST released working drafts showing how Personal Identity Verification credentials could support ML-KEM and ML-DSA. The proposed approach uses a dual stack that preserves existing classical objects while adding new post-quantum keys, certificates, and data structures. That illustrates a likely pattern for real deployments: incremental transition and backward compatibility rather than a single global switch.

The US government also issued an executive action and Office of Management and Budget memorandum directing federal agencies to establish migration leadership, inventory cryptographic systems, create prioritized plans, and mitigate quantum risk in owned or operated systems with a target of December 31, 2030. Those requirements apply directly to federal agencies, but suppliers and software vendors should expect the work to influence procurement and product roadmaps.

The deadlines do not predict when a cryptographically relevant quantum computer will arrive. They reflect how long large organizations need to replace embedded cryptography safely.

A Practical Migration Starts With Inventory

Cryptography is often invisible to asset-management tools. It may be built into web servers, certificates, identity systems, databases, mobile applications, firmware, code-signing pipelines, hardware security modules, backup systems, industrial devices, partner connections, and third-party services.

A useful inventory records the algorithm, key size, protocol, certificate authority, software library, hardware dependency, data sensitivity, expected product lifetime, vendor owner, and upgrade path. The organization can then prioritize systems that protect long-lived data or perform critical authentication.

This is not only a security-team project. Application owners, procurement, vendors, infrastructure teams, legal and compliance staff, and business leaders all control parts of the migration.

Hybrid Deployment Can Reduce Transition Risk

During a transition, some protocols combine a classical algorithm with a post-quantum algorithm. The goal is to retain protection if one component later proves weak or if older systems still need compatibility. Hybrid designs can be valuable, but they add complexity, larger messages, more processing, and additional failure modes.

Organizations should use combinations defined by reputable protocol communities and supported by maintained products. Inventing a private hybrid scheme is not crypto agility. It creates another custom dependency that will be difficult to validate and replace.

Crypto Agility Is the Long-Term Capability

No algorithm should be treated as permanent. Implementations can fail, standards can change, and new research can alter confidence. Crypto agility means an organization can identify, replace, configure, test, and monitor cryptographic components without rebuilding every application.

That requires supported libraries, clear interfaces, automated certificate management, test environments, vendor commitments, and configuration policies. It also requires avoiding hard-coded assumptions about key lengths, signature sizes, or certificate formats, because post-quantum objects can be larger than their classical predecessors.

Post-Quantum Cryptography Is Not Quantum Key Distribution

Post-quantum algorithms run on conventional computers and networks. Quantum key distribution uses specialized physical links and quantum hardware to distribute key material. QKD may be useful in narrow environments, but it requires dedicated infrastructure and does not secure endpoints or replace ordinary authentication.

The US National Security Agency currently emphasizes standardized quantum-resistant algorithms for national security systems and identifies significant engineering, cost, validation, and denial-of-service limitations in QKD. The emerging quantum networking field should therefore not be confused with the software migration organizations need today.

What Consumers and Small Organizations Should Do

Most individuals should not install experimental cryptography or buy products that promise vaguely defined “quantum-proof” protection. Keep operating systems, browsers, messaging applications, routers, and security software updated so mature protocol changes arrive through supported vendors.

Small organizations should ask cloud, identity, certificate, network, and software suppliers for post-quantum roadmaps. They can begin documenting certificates and cryptographic dependencies now, especially for systems with long service lives.

The basics still matter. Multi-factor authentication, passkeys, backups, patching, access control, and phishing resistance address immediate risks discussed in our guide to AI phishing and passkeys. Post-quantum migration does not compensate for weak passwords or compromised endpoints.

A Five-Step Readiness Checklist

1. Find cryptography: inventory certificates, protocols, libraries, devices, data stores, and supplier dependencies.
2. Prioritize: focus on long-lived sensitive data, critical identities, code signing, and systems with slow replacement cycles.
3. Ask vendors: require standards-based roadmaps, supported upgrade paths, testing evidence, and lifecycle commitments.
4. Pilot safely: test approved post-quantum or hybrid configurations in controlled environments and measure performance and compatibility.
5. Build agility: make cryptographic components observable and replaceable so this is not the last painful migration.

What to Watch Next

Watch for final migration timelines, protocol standards from groups such as the IETF, validated cryptographic modules, post-quantum certificate deployments, updated identity credentials, and product support that is enabled by default rather than hidden behind experiments.

Post-quantum cryptography is now an implementation program, not a distant thought exercise. The best preparation is disciplined engineering: know what you use, protect the data with the longest lifetime, follow tested standards, and preserve the ability to change again.

Sources and Further Reading

• NIST: First Three Finalized Post-Quantum Cryptography Standards
• NIST: 2026 Working Drafts for Post-Quantum PIV Credentials
• OMB Memorandum M-26-15: Execution of the Migration to Post-Quantum Cryptography
• CISA, NSA, and NIST: Quantum-Readiness Migration Roadmap
• NSA: Post-Quantum Cybersecurity Resources

Cybersecurity is entering a new phase. Attackers can use AI tools to write convincing messages, translate scams, imitate support conversations, and generate content at scale. At the same time, defenders are moving toward stronger identity systems such as passkeys.

The result is a shift from simple password advice to a broader focus on trust: who is asking, what action is requested, which device is involved, and whether the request matches normal behavior.

Why AI Phishing Is Different

Traditional phishing messages often contained obvious grammar mistakes or suspicious formatting. AI-generated messages can be cleaner, more personalized, and easier to produce in many languages. That lowers the cost of deception.

Businesses and consumers need to be careful with urgent requests, payment changes, login links, file downloads, and messages that ask for sensitive information. Verification through a separate trusted channel is still one of the strongest defenses.

Passkeys and the Password Problem

Passkeys are designed to reduce reliance on passwords by using cryptographic authentication tied to a device or account. They can be easier for users and harder for attackers to steal through fake login pages. Adoption is still ongoing, but the direction is promising.

Practical Security Habits

• Use a password manager for accounts that still require passwords.
• Turn on multi-factor authentication where passkeys are not available.
• Keep devices and browsers updated.
• Verify sensitive requests through a second channel.
• Limit what personal information is shared publicly.

Cybersecurity is no longer only an IT department problem. It is part of everyday digital life, and AI makes clear habits more important than ever.