Architecture·January 2025·10 min read

Future of Cybersecurity: Innovations and Strategies

Cybersecurity for commerce systems in 2026 is governance work and migration work, not the blockchain-identity hype cycle of a few years ago. NIST CSF 2.0 made governance a formal function, NIST finalized three post-quantum cryptography standards in 2024, and passkeys, not decentralized identity, are what actually replaced passwords at scale.

Governance became a named function, not an afterthought

NIST published Cybersecurity Framework 2.0 in February 2024, and the headline change is a sixth core function: Govern, alongside Identify, Protect, Detect, Respond, and Recover (NIST — Cybersecurity Framework). Govern is cross-cutting by design. It covers organizational context, risk management strategy, supply chain risk management, and oversight, and it's meant to inform how the other five functions get implemented (NIST CSWP 29 — The NIST Cybersecurity Framework 2.0).

For a commerce business, that's not an academic distinction. A PCI DSS scope decision, a decision about which payment processor holds card data, and a decision about which third-party checkout widget gets embedded are all governance decisions before they're technical ones. CSF 2.0 gives them a formal home in the framework instead of leaving them implicit.

What this changes in practice

Teams that treated cybersecurity as a Protect-and-Detect problem, firewalls plus a SIEM, now have an explicit framework category for supply chain risk and for defining who owns a risk decision. That matters most at the exact moment a business adds a new payment integration, a new analytics pixel, or a new AI vendor with access to customer data.

Govern isn't a seventh box to check after the technical work. CSF 2.0 treats it as the function that determines how the other five get implemented, starting with who owns the decision to accept a given risk.

Post-quantum cryptography stopped being theoretical in August 2024

NIST finalized three post-quantum cryptography standards on August 13, 2024, after an eight-year public standardization process (NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards):

FIPS 203 (ML-KEM): a lattice-based key-encapsulation mechanism, derived from CRYSTALS-Kyber, that replaces RSA and ECDH for key exchange (NIST — FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard).
FIPS 204 (ML-DSA): a lattice-based digital signature algorithm intended as the primary replacement for RSA and ECDSA signatures (NIST — FIPS 204, Module-Lattice-Based Digital Signature Standard).
FIPS 205 (SLH-DSA): a stateless, hash-based signature scheme derived from SPHINCS+, offered as a conservative fallback whose security doesn't depend on lattice-hardness assumptions (NIST — FIPS 205, Stateless Hash-Based Digital Signature Standard).

None of this is about quantum computers existing today. It's about "harvest now, decrypt later": an adversary who records TLS traffic or encrypted backups now can decrypt them once a cryptographically relevant quantum computer exists. For commerce systems, that means anything encrypted today with a long confidentiality requirement, stored payment tokens, customer PII, order history, is already exposed to that future risk.

The migration path CISA, NSA, and NIST recommend

CISA runs a Post-Quantum Cryptography Initiative that tracks federal migration, and jointly with NSA and NIST it published a quantum-readiness roadmap aimed at any organization, not just federal agencies (CISA — Post-Quantum Cryptography Initiative, CISA, NSA, NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography). The recommended sequence starts with a cryptographic inventory: knowing where RSA and elliptic-curve algorithms are actually used across TLS termination, code signing, and payment tokenization before deciding what to migrate first.

The PQC migration path CISA, NSA, and NIST recommend: inventory first, then prioritize by how long a secret needs to stay confidential, then run classical and post-quantum algorithms in hybrid mode before a full cutover.

Hybrid deployment, running a classical algorithm and a PQC algorithm side by side during transition, is the practical middle step most vendors are shipping toward. A full, one-shot cutover to FIPS 203/204/205 without a hybrid period is realistic for very few organizations given how deeply RSA and ECC are embedded in TLS libraries, HSMs, and payment gateway SDKs.

Algorithm family	Primary use	Status for commerce systems
RSA / ECDH (classical)	Key exchange, TLS	Still the default everywhere; vulnerable to future quantum attack on recorded traffic
ML-KEM / FIPS 203	Key exchange, TLS	Standardized, shipping in hybrid mode in some browsers and TLS libraries
RSA / ECDSA (classical)	Digital signatures, code signing	Still the default; long-lived signed artifacts carry the same harvest-now risk
ML-DSA / FIPS 204	Digital signatures	Standardized; primary PQC signature replacement
SLH-DSA / FIPS 205	Digital signatures (fallback)	Standardized; conservative hash-based option if lattice assumptions are ever broken

Passwords were always the weak link; passkeys fixed it, not blockchain identity

A few years ago, the pitch for fixing password-based authentication was decentralized identity built on blockchain. That pitch mostly stalled. What actually shipped, at browser, OS, and platform scale, is WebAuthn and FIDO2 passkeys, standardized jointly by the W3C and the FIDO Alliance (W3C — Web Authentication, Level 3, FIDO Alliance — Passkeys).

A passkey is a public-key credential bound to a device or synced through a platform account, unlocked with the same biometric or PIN a user already uses to unlock the device. There's no shared secret transmitted to a server and no password database to breach, which removes credential stuffing and phishing-by-fake-login-page as viable attack paths against that credential.

NIST's own digital identity guidelines have kept pace: SP 800-63B recognizes syncable passkeys as a legitimate authenticator type for federal systems, not just a consumer convenience feature (NIST SP 800-63B — Digital Identity Guidelines, Authentication and Lifecycle Management).

Decentralized identity on blockchain was the pitch. Passkeys, standardized through W3C WebAuthn and the FIDO Alliance, are what actually shipped at scale and what NIST's own authenticator guidance now recognizes.

Why this matters for account takeover in commerce

Account takeover (ATO) against customer accounts holding stored payment methods is one of the highest-value fraud paths in commerce, because a compromised account skips the card-verification step an attacker would otherwise face at checkout. Passkeys remove the credential-stuffing and phishing vectors that make ATO cheap at scale, since there's no reusable password to steal in the first place.

The rollout cost is real: passkeys require a account-recovery story for lost devices, and most commerce platforms need to run passkeys alongside passwords for existing accounts during a long transition. That's a product and support-flow decision as much as a security one.

API security is the actual commerce attack surface

Storefronts, mobile apps, and third-party integrations all talk to the same backend through APIs, and that's where OWASP's dedicated API Security Top 10 is more relevant to a commerce stack than the general web Top 10 alone (OWASP API Security Top 10, 2023 edition, OWASP Top 10).

OWASP API risk	What it looks like in commerce
Broken object level authorization (BOLA)	Order or address ID incremented in a URL exposes another customer's order
Broken authentication	Password-reset or session-token flow reused across account and admin endpoints
Broken object property level authorization	A price or discount field editable client-side gets accepted server-side without revalidation
Unrestricted resource consumption	A public product-search or coupon-validation endpoint with no rate limit, abused for scraping or brute-forcing codes
Server-side request forgery	A webhook or "import product image from URL" feature used to reach internal infrastructure

BOLA in particular shows up constantly in commerce backends because order, cart, and address objects are usually keyed by a simple ID, and the authorization check that should confirm "does this session own this order" is easy to skip under deadline pressure. It's the single most common finding in commerce API assessments, and it's also the cheapest to fix: check ownership server-side, on every object-scoped request, with no exceptions for internal admin tooling.

Supply chain risk: know what's actually in your build

A software bill of materials (SBOM) is a nested inventory of the components that make up a piece of software, and CISA coordinates the baseline for what a usable one contains (CISA — Software Bill of Materials). For commerce specifically, the relevant failure mode is a compromised third-party script, a checkout widget, an analytics tag, a chat plugin, injected with card-skimming code that runs silently on the payment page.

An SBOM doesn't prevent that kind of compromise by itself. What it does is make the question "which of our dependencies just got a CVE" answerable in minutes instead of days, and that speed is what limits exposure window on a live storefront.

Generate an SBOM for every service that touches checkout, payment, or customer PII, not just the core application.
Include third-party JavaScript loaded directly into the checkout page, not only server-side dependencies.
Wire SBOM diffing into CI so a new or changed dependency triggers a review, not a silent merge.
Subscribe the SBOM tooling to a CVE feed scoped to the actual components in use, not a generic industry feed.

Red Team, Blue Team, and the case for Purple Team by default

NIST's guide to security and privacy testing, SP 800-115, lays out the technical methodology behind adversarial testing: network discovery, vulnerability scanning, penetration testing, and the review processes that should surround them (NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment). Red Team exercises simulate an attacker against that methodology; Blue Team is the defending side reading the same signals in real time.

Running them as two separate exercises with a report handed over weeks later wastes most of the value. A Purple Team model, where the two sides collaborate during the engagement instead of after it, turns a Red Team finding into a Blue Team detection rule the same day, which is the actual point of the exercise.

Scope the exercise around a specific commerce flow, checkout, account recovery, admin access, not the whole infrastructure at once.
Have the Blue Team's detection tooling live and logging during the Red Team's attempt, not reviewed after the fact.
Convert every successful Red Team technique into a detection rule or a code fix before closing the engagement.

FAQ

Do we need to migrate to post-quantum cryptography right now?

Most commerce businesses don't control their own TLS stack down to the algorithm level, that sits with CDNs, cloud load balancers, and payment gateways. The action available now is a cryptographic inventory and a conversation with those vendors about their PQC and hybrid-mode timeline, per the CISA, NSA, and NIST roadmap.

Are passkeys ready to replace passwords entirely for a storefront's customer accounts?

They're ready as an option alongside passwords, not yet as a full replacement, because account recovery for lost devices and cross-platform sync still varies by implementation. NIST SP 800-63B treats syncable passkeys as a legitimate authenticator, which is the relevant bar for adoption.

What's the single highest-value API fix for a commerce backend?

Server-side ownership checks on every object-scoped endpoint, order, cart, address, payment method. Broken object level authorization is consistently the most common and most exploitable finding in commerce API assessments.

Is an SBOM only relevant for compliance, or does it help day to day?

It helps day to day. The practical value is answering "are we exposed to this new CVE" in minutes rather than days, which directly limits how long a vulnerable dependency stays live on a payment-adjacent page.

What replaced the "decentralized identity on blockchain" pitch from a few years ago?

WebAuthn and FIDO2 passkeys, standardized through the W3C and FIDO Alliance, are what shipped at browser and platform scale. Blockchain-based decentralized identity frameworks didn't reach comparable adoption.

Should Red Team and Blue Team stay separate exercises?

Running them together as a Purple Team engagement, with the Blue Team's tooling live during the Red Team's attempt, converts findings into detection rules the same day instead of weeks later in a report.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.