DEV Community: Fuad Husnan

Event-Driven Design: Building Real-Time Streams with WebSockets and Webhooks

Fuad Husnan — Sat, 05 Sep 2026 11:51:38 +0000

Event-driven design turns your backend from a system that waits to be asked into one that reacts as things happen. Instead of clients polling an endpoint every few seconds to check "did anything change yet," the server pushes updates the moment they occur. Two mechanisms do most of the heavy lifting here: WebSockets and webhooks. They solve different halves of the same problem, and most production systems that claim to be "real-time" are actually running both at once.

This guide breaks down how each one works, when to reach for it, and how to wire them together without turning your event pipeline into a source of on-call pages.

Why Polling Doesn't Scale

Before event-driven patterns took over, the default was polling: a client hits an API every few seconds, checks a timestamp or a status field, and does nothing 95% of the time. It works, but it wastes requests, adds latency proportional to your polling interval, and gets expensive fast once you have thousands of clients doing it simultaneously.

Event-driven architectures flip this. A backend receives an event, validates it, stores it, and hands it off to whatever needs to act on it. Polling still has a place as a fallback or reconciliation mechanism, but it's rarely the first choice once a system can push events instead of waiting to be asked.

The distinction that actually matters when picking your mechanism isn't "is this real-time" — both WebSockets and webhooks are real-time in the sense that they avoid polling delay. The distinction is who initiates the connection and whether that connection stays open.

WebSockets: Persistent, Bidirectional Connections

A WebSocket starts as an ordinary HTTP request. The client sends an Upgrade: websocket header, the server responds with HTTP 101 Switching Protocols, and from that point on the connection stops speaking HTTP entirely. What's left is a raw TCP socket with a thin framing layer — no headers per message, no request-response cycle, just a persistent, full-duplex pipe. Removing HTTP overhead from every message is what makes WebSockets so much cheaper per message than repeated HTTP calls.

That persistence is the whole value proposition. Once the handshake completes, either side can send data at any time without renegotiating a connection. This is why WebSockets are the natural fit for chat applications, live dashboards, multiplayer games, and collaborative editors — anywhere the client is a browser or mobile app that needs to both receive pushes and send messages back on the same channel.

Here's a minimal WebSocket server in Node.js using the ws library:

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (socket) => {
  console.log('Client connected');

  socket.on('message', (data) => {
    const event = JSON.parse(data);
    console.log('Received event:', event.type);

    // Broadcast to all connected clients
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify({
          type: 'broadcast',
          payload: event.payload,
          timestamp: Date.now()
        }));
      }
    });
  });

  socket.on('close', () => {
    console.log('Client disconnected');
  });
});

And a corresponding browser client:

const socket = new WebSocket('wss://your-server.com:8080');

socket.addEventListener('open', () => {
  socket.send(JSON.stringify({
    type: 'subscribe',
    payload: { channel: 'order-updates' }
  }));
});

socket.addEventListener('message', (event) => {
  const data = JSON.parse(event.data);
  console.log('Update received:', data);
});

The trade-off is that "always on" comes with real operational cost. A WebSocket server has to hold connection state in memory for every connected client, which means scaling horizontally requires a pub/sub layer so that a message published on one node reaches a client connected to a different node. You also have to handle reconnects, heartbeats to detect dead connections, and uneven client network conditions. Keeping state coherent across all of that under load is the actual hard part of "real-time" — the streaming itself is the easy half.

Webhooks: Stateless, One-Way Notifications

A webhook is the opposite shape. It's a plain HTTP POST request sent from one application to another when a specific event happens. There's no persistent connection and no handshake to maintain — each event is an independent, stateless HTTP call. The source system decides something happened, fires a request at a URL you registered in advance, and moves on. Your server receives it, acknowledges it, and does whatever it needs to do with the payload.

This makes webhooks the right tool whenever the receiving side doesn't need to talk back on the same channel — payment confirmations, repository push notifications, CRM record updates, or any server-to-server event where "tell me when X happens" is the entire requirement. Webhooks don't help when the client is a browser that can't expose a public endpoint of its own, and they're inherently one-directional, which is exactly why they pair so well with WebSockets rather than replacing them.

A basic webhook receiver in Express looks like this:

const express = require('express');
const crypto = require('crypto');

const app = express();
app.use(express.json());

const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;

function verifySignature(req) {
  const signature = req.headers['x-webhook-signature'];
  const payload = JSON.stringify(req.body);
  const expected = crypto
    .createHmac('sha256', WEBHOOK_SECRET)
    .update(payload)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}

app.post('/webhooks/orders', (req, res) => {
  if (!verifySignature(req)) {
    return res.status(401).json({ error: 'Invalid signature' });
  }

  const { event, data } = req.body;

  // Acknowledge immediately, process asynchronously
  res.status(200).json({ received: true });

  processOrderEvent(event, data).catch((err) => {
    console.error('Failed to process webhook:', err);
    // route to retry queue or dead-letter storage
  });
});

app.listen(3000);

Two details in that snippet matter more than they look. First, signature verification with timingSafeEqual prevents timing attacks against your secret comparison — a plain === check leaks information about how many characters matched. Second, the handler responds before processing finishes. Webhook senders enforce timeouts and will retry on anything that looks like a failure, so slow synchronous processing inside the request handler is a common cause of duplicate deliveries.

That duplication risk is structural, not a bug you can code around. If your server doesn't respond fast enough, or the response is lost in transit, the sender assumes failure and retries — which means your endpoint needs to be idempotent. Track processed event IDs and skip anything you've already handled.

Fragmentation Is the Real Cost of Webhooks

The retry problem is solvable with idempotency keys. The harder problem is that every webhook provider has historically implemented its own signature scheme, retry policy, and payload shape. Handling ten providers has meant writing ten different verifiers and ten different retry assumptions.

The Standard Webhooks specification exists specifically to close that gap. It defines a common signing scheme, delivery format, and verification approach so that consumers don't have to relearn webhook handling for every new integration. As of 2026, it has been adopted by a range of companies including OpenAI, Anthropic, Google Gemini, Twilio, PagerDuty, and Supabase, among others — worth checking for before you write yet another one-off signature verifier from scratch.

On the payload side, CloudEvents has become the closest thing to a vendor-neutral standard for structuring the event body itself:

{
  "specversion": "1.0",
  "type": "com.example.order.created",
  "source": "/orders/service",
  "id": "A234-1234-1234",
  "time": "2026-01-25T17:31:00Z",
  "datacontenttype": "application/json",
  "data": {
    "orderId": "12345",
    "amount": 99.99
  }
}

If you're building a system that emits webhooks to your own customers, aligning early with Standard Webhooks for delivery and CloudEvents for payload shape saves you from designing a bespoke format that every integrator has to learn from scratch.

Combining Both in One Architecture

Most systems that need to feel real-time end up running WebSockets and webhooks side by side rather than choosing one. A typical e-commerce flow illustrates why: a payment provider fires a webhook when a charge succeeds, your backend updates the order record, and then that update needs to reach the customer's browser instantly. That last leg is a WebSocket push, not another webhook, because the browser has no public endpoint to receive one.

const express = require('express');
const WebSocket = require('ws');

const app = express();
app.use(express.json());

const wss = new WebSocket.Server({ port: 8080 });
const clientsByOrder = new Map(); // orderId -> Set of sockets

wss.on('connection', (socket, req) => {
  const orderId = new URL(req.url, 'http://localhost').searchParams.get('orderId');
  if (!clientsByOrder.has(orderId)) {
    clientsByOrder.set(orderId, new Set());
  }
  clientsByOrder.get(orderId).add(socket);

  socket.on('close', () => clientsByOrder.get(orderId)?.delete(socket));
});

app.post('/webhooks/payment', express.json(), (req, res) => {
  const { orderId, status } = req.body;
  res.status(200).json({ received: true });

  updateOrderStatus(orderId, status).then(() => {
    const subscribers = clientsByOrder.get(orderId);
    if (subscribers) {
      const message = JSON.stringify({ type: 'order-status', orderId, status });
      subscribers.forEach((client) => {
        if (client.readyState === WebSocket.OPEN) client.send(message);
      });
    }
  });
});

This pattern — webhook in, database update, WebSocket push out — is the backbone of most "live" dashboards you've used. The webhook handles the reliable, asynchronous, server-to-server leg. The WebSocket handles the low-latency leg to a connected browser. Neither one replaces the other; they're doing different jobs in the same pipeline.

Operational Realities Worth Planning For

Building the happy path for either mechanism takes an afternoon. Making it production-grade is where the real time goes. For webhooks, budget for retry queues, dead-letter handling, and a delivery dashboard so you can see what failed and why — this consistently takes longer than teams expect, which is exactly why platforms like Svix, Hookdeck, and Convoy exist to take it off your plate if you're sending webhooks to your own customers, or Nango and similar tools if you're receiving them from external providers.

For WebSockets, the equivalent tax is connection lifecycle management: heartbeats to detect half-open connections, reconnection logic on the client, and a pub/sub layer (Redis, NATS, or a managed service) so that broadcasts reach clients regardless of which server instance they're connected to. None of this is optional past a handful of concurrent users — it's the difference between a demo and a system that survives a network blip.

Choosing Between Them

The decision comes down to three questions. Does the receiving side need to send data back on the same channel, or is a one-way notification enough? Can the receiver expose a public HTTP endpoint, or is it a browser/mobile client sitting behind NAT? And does the interaction represent a continuous session, or a series of discrete events with gaps between them?

A trading terminal or multiplayer game is a continuous session — WebSockets. A payment confirmation or repository update is a discrete, one-way event — a webhook. Most real systems have both kinds of interaction happening simultaneously, which is why the architectures that hold up under load treat WebSockets and webhooks as complementary tools rather than competing choices.

If you're starting from scratch, don't build the retry infrastructure or the connection-scaling layer yourself before you need to. Start with the standard patterns above, adopt Standard Webhooks and CloudEvents where they fit, and reach for dedicated infrastructure once your event volume justifies the operational overhead of running it in-house.

GraphQL vs. gRPC: Choosing Your Modern API Stack

Fuad Husnan — Sat, 05 Sep 2026 11:35:31 +0000

A fintech team spends eight months migrating its entire backend to GraphQL because it "sounded modern," then watches performance degrade under load because every mobile client is now issuing deeply nested queries the resolver layer was never built to handle. Meanwhile, a logistics company bolts gRPC onto its public-facing customer API, only to discover that partner developers can't test an endpoint without generating client stubs first. Both teams solved a problem they didn't have and created one they didn't expect. GraphQL and gRPC are not competing answers to the same question — they optimize for different consumers, different network conditions, and different failure modes, and mixing up which is which is what causes the expensive rewrites.

This guide breaks down what each technology actually does well, where the tradeoffs bite, and how to decide between them — or combine them — for a real production system.

What GraphQL Actually Solves

GraphQL is a query language for APIs, developed to let clients ask for exactly the fields they need in a single request, no more, no less. It replaces the common REST pattern of hitting five endpoints to assemble one screen with a single POST to a /graphql endpoint carrying a query document.

The core motivation is over-fetching and under-fetching. A mobile app rendering a product card doesn't need the full product record REST would return, and a dashboard aggregating data from three domains shouldn't need three round trips. GraphQL's schema-first design also gives frontend teams a strongly typed contract they can introspect, generate types from, and build tooling around without waiting on backend changes for every new view.

Here's a minimal schema and resolver in Node.js using Apollo Server:

const { ApolloServer, gql } = require('apollo-server');

const typeDefs = gql`
  type Product {
    id: ID!
    name: String!
    price: Float!
    reviews: [Review!]!
  }

  type Review {
    author: String!
    rating: Int!
  }

  type Query {
    product(id: ID!): Product
  }
`;

const resolvers = {
  Query: {
    product: async (_, { id }, { dataSources }) => {
      return dataSources.productAPI.getProduct(id);
    },
  },
  Product: {
    reviews: async (product, _, { dataSources }) => {
      return dataSources.reviewAPI.getReviewsForProduct(product.id);
    },
  },
};

const server = new ApolloServer({ typeDefs, resolvers });
server.listen().then(({ url }) => {
  console.log(`GraphQL server ready at ${url}`);
});

A client can now request just the product name and its reviewers' ratings in one call, and the resolver layer handles fetching from whatever underlying services back each field. That flexibility is the entire value proposition, and it's real: teams building for multiple client platforms — iOS, Android, web — with different data needs per screen benefit from not maintaining parallel REST endpoints for each variant.

The tradeoffs show up in production, not in the demo. Caching is one of the sharpest: because every GraphQL request goes to the same endpoint with a different query body, the HTTP caching layer that works so well for REST — ETags, Cache-Control, CDN edge caching by URL — is essentially broken due to the single endpoint architecture. Query complexity is another. A poorly constrained schema lets a client request nested relationships that fan out into dozens of downstream calls, and without depth limiting or cost analysis, a single query can accidentally DoS your own database. Adoption data reflects this maturing understanding: GraphQL adoption sits at roughly 25% among enterprise teams, down from a peak near 40%, concentrated in organizations with complex frontend data requirements across multiple client platforms. That's not decline so much as correction — teams that adopted GraphQL for simple CRUD backends are moving back to REST, while teams with genuinely complex data-fetching needs are staying.

What gRPC Actually Solves

gRPC is a remote procedure call framework built by Google on top of HTTP/2 and Protocol Buffers. Instead of a client asking "give me this JSON resource," it calls a method on a service as if it were a local function, and the framework handles serialization, transport, and streaming underneath.

The design center is service-to-service communication inside a system you control end to end — typically microservices in the same cluster or mesh. Protocol Buffers serialize to a compact binary format instead of text-based JSON, which cuts payload size and parsing overhead substantially. HTTP/2 gives gRPC native support for bidirectional streaming, multiplexed requests over a single connection, and built-in flow control — capabilities REST over HTTP/1.1 never had and that GraphQL, running over HTTP/1.1 POST in most implementations, doesn't get either.

A basic .proto definition and Python server implementation illustrate the contract-first approach:

syntax = "proto3";

package inventory;

service InventoryService {
  rpc GetProduct (ProductRequest) returns (ProductResponse);
  rpc StreamStockUpdates (StockRequest) returns (stream StockUpdate);
}

message ProductRequest {
  string product_id = 1;
}

message ProductResponse {
  string id = 1;
  string name = 2;
  double price = 3;
}

message StockRequest {
  string warehouse_id = 1;
}

message StockUpdate {
  string product_id = 1;
  int32 quantity = 2;
}

import grpc
from concurrent import futures
import inventory_pb2
import inventory_pb2_grpc

class InventoryServicer(inventory_pb2_grpc.InventoryServiceServicer):
    def GetProduct(self, request, context):
        product = fetch_product_from_db(request.product_id)
        return inventory_pb2.ProductResponse(
            id=product.id, name=product.name, price=product.price
        )

    def StreamStockUpdates(self, request, context):
        for update in subscribe_to_warehouse(request.warehouse_id):
            yield inventory_pb2.StockUpdate(
                product_id=update.product_id, quantity=update.quantity
            )

server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
inventory_pb2_grpc.add_InventoryServiceServicer_to_server(InventoryServicer(), server)
server.add_insecure_port('[::]:50051')
server.start()
server.wait_for_termination()

The performance case for gRPC is well documented and consistent across independent benchmarks. Enterprise deployments show gRPC outperforming REST by 5–10x in throughput for internal microservice-to-microservice interactions, and at the latency level, published comparisons put gRPC's p50 latency at roughly 0.1ms versus REST's 0.3ms, with p99 at 12ms versus 45ms. At companies operating hundreds of internal services, gRPC now handles billions of internal RPCs per day, with 7-10x performance gains over JSON-based REST for serialization-heavy workloads. That's the number that matters for infrastructure teams: at scale, the difference between binary Protobuf and JSON parsing compounds across every hop in a call chain.

The costs are on the developer-experience and interoperability side. You cannot curl a gRPC endpoint the way you can a REST or GraphQL one; debugging requires grpcurl or a generated client, and inspecting traffic in a tool like Wireshark shows binary noise without the corresponding .proto file. Browser support is also incomplete — native gRPC requires HTTP/2 trailers that browsers don't expose directly, which is why gRPC-Web exists as a translation layer, adding a proxy hop for any browser-facing use case. This is precisely why gRPC rarely appears as a public, partner-facing API: onboarding a third-party developer to a binary RPC protocol with generated stubs is a much higher bar than handing them a REST endpoint and a Postman collection.

Making the Actual Decision

The honest framing is that GraphQL and gRPC rarely compete for the same slot in an architecture. GraphQL competes with REST at the client-facing edge, where flexible data-fetching for a variety of frontends is the priority. gRPC competes with REST (and with things like Kafka for async cases) in the service mesh, where raw throughput and strict contracts between services you control matter more than developer accessibility.

The pattern showing up repeatedly in 2026 architecture writeups is a layered one: internal services communicate over gRPC for speed and type safety, and a GraphQL layer sits in front as a client-facing gateway that aggregates those services into flexible queries for web and mobile apps. This is described as the most common current pattern, and it lets each protocol do the job it's actually good at instead of forcing one technology to cover both the internal and external surface.

A few concrete questions cut through most of the ambiguity. If the consumer is a third-party developer or a partner you don't control, gRPC is the wrong choice regardless of its performance advantages — the integration friction will show up in support tickets, not benchmarks. If the client is a single-purpose mobile app hitting two or three well-known endpoints, plain REST is often sufficient, and GraphQL adds schema and resolver overhead for no real benefit. If you're aggregating data from many internal services into varied frontend views, GraphQL's flexibility earns its complexity. If you're building latency-sensitive internal service-to-service calls — recommendation engines, real-time inventory checks, anything where milliseconds compound across a call chain — gRPC's binary serialization and HTTP/2 streaming are worth the tooling cost.

Team expertise deserves more weight in this decision than it usually gets. A well-implemented REST API consistently outperforms a poorly implemented GraphQL or gRPC service in real production incidents, because the failure modes of an unfamiliar protocol — unbounded query depth in GraphQL, misconfigured deadlines in gRPC — tend to surface under load, not in code review. Migration cost is also not trivial: teams moving an existing protocol to either alternative should plan for meaningfully more build effort than the greenfield estimates suggest, and an incremental rollout behind an API gateway is safer than a full cutover.

Where This Leaves You

Neither technology deprecates REST, and neither is a default choice you reach for because it's the newer name in the room. GraphQL earns its place when the problem is genuinely about flexible, client-driven data shaping across multiple frontends. gRPC earns its place when the problem is internal service throughput, and you control both ends of the wire. If your system needs both — a fast internal mesh and a flexible public-facing surface — running gRPC underneath a GraphQL gateway is a proven pattern, not a compromise.

Before committing either way, map your actual traffic: who's calling this API, how many different data shapes do they need, and where does latency currently hurt? That answer, not the technology's reputation, should decide your stack.

Building a Modern API: Best Practices for 2026 and Beyond

Fuad Husnan — Sat, 05 Sep 2026 11:30:53 +0000

A team shipping a "quick" endpoint today is making a promise they'll have to keep for years. Building a modern API in 2026 means designing for change from the first commit, not patching predictability after a breaking release that burns your integration partners. This guide walks through the architectural decisions, patterns, and code-level practices that separate APIs teams are still trusted in year five from those that get rewritten in year two.

Pick the Right Protocol for Each Boundary, Not for the Whole System

The old debate — REST versus GraphQL versus gRPC — has mostly resolved itself. The mature answer isn't "which one wins," it's "which protocol fits which boundary in your system." A typical modern stack uses gRPC for service-to-service calls where latency and type safety matter, REST for public-facing partner APIs where broad compatibility wins, and GraphQL as a backend-for-frontend layer when different clients need different slices of the same data.

REST remains the default for anything a browser or third-party developer calls directly. It's simple, cacheable over standard HTTP, and every developer already knows how to consume it. GraphQL earns its added complexity when a mobile app and a web dashboard need very different fields from the same underlying resources, and making multiple round trips to assemble a screen becomes wasteful. gRPC, built on Protocol Buffers and HTTP/2, delivers markedly lower latency and smaller payloads, which is why it dominates internal microservice communication where both sides of the wire are under your control.

The practical takeaway: don't force one protocol to solve every problem in your architecture. Match the tool to the constraint at each boundary — internal speed, external reach, or per-client data shaping — rather than picking a single technology as an organizational identity.

Design Resources and Endpoints Around Nouns, Not Actions

For REST APIs specifically, resource modeling still trips up more teams than any other decision. Endpoints should represent things (/orders, /customers/42/invoices), not verbs (/getOrder, /createInvoice). HTTP methods already carry the verb.

# FastAPI example: resource-oriented routing
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

class Order(BaseModel):
    id: int
    customer_id: int
    status: str
    total_cents: int

orders_db: dict[int, Order] = {}

@app.get("/orders/{order_id}")
def get_order(order_id: int) -> Order:
    if order_id not in orders_db:
        raise HTTPException(status_code=404, detail="Order not found")
    return orders_db[order_id]

@app.post("/orders", status_code=201)
def create_order(order: Order) -> Order:
    orders_db[order.id] = order
    return order

Keep nesting shallow. /customers/42/invoices/17/line-items is technically valid but painful to maintain and version. Two levels of nesting is usually the practical ceiling; beyond that, expose a flatter resource with a filter parameter instead, such as /line-items?invoice_id=17.

Paginate Before It's a Problem

Returning an entire collection in one response works fine in a demo and falls over in production. Offset-based pagination (?page=3&limit=50) is easy to implement but degrades as tables grow, since the database still has to scan and discard all the skipped rows. Cursor-based pagination avoids that by using an opaque pointer to the last seen record, which keeps query performance roughly constant regardless of table size.

// Cursor-based pagination with a Postgres-backed API (Node/Express)
app.get('/api/orders', async (req, res) => {
  const { cursor, limit = 25 } = req.query;
  const pageSize = Math.min(Number(limit), 100);

  const query = cursor
    ? 'SELECT * FROM orders WHERE id > $1 ORDER BY id ASC LIMIT $2'
    : 'SELECT * FROM orders ORDER BY id ASC LIMIT $1';
  const params = cursor ? [cursor, pageSize] : [pageSize];

  const { rows } = await pool.query(query, params);
  const nextCursor = rows.length === pageSize ? rows[rows.length - 1].id : null;

  res.json({ data: rows, next_cursor: nextCursor });
});

Set a sensible cap on limit server-side. Letting clients request unbounded page sizes is a common, self-inflicted denial-of-service vector.

Version for Change, Not Just for Launch

Every API you ship is a promise to the people who integrate with it. The version scheme you choose determines how painful the next breaking change will be — and there will be a next breaking change. Semantic versioning combined with automated breaking-change detection in CI catches accidental contract violations before they reach a partner's production system, rather than after a support ticket arrives.

URL-based versioning (/v1/orders, /v2/orders) is the most common approach because it's visible and simple to route. Header-based versioning is more elegant but harder for developers to debug when something silently changes. Whichever you choose, commit to a deprecation policy in writing: how long old versions stay live, how you notify integrators, and what constitutes a breaking versus non-breaking change. Adding an optional field is non-breaking; renaming or removing one is.

Build Authentication and Authorization as Separate Concerns

Authentication answers "who is this"; authorization answers "what can they do." Conflating the two is a common source of security bugs. OAuth 2.0 with short-lived JWTs remains the standard for user-facing APIs, while service-to-service calls typically rely on mutual TLS or signed service tokens.

# FastAPI dependency separating auth from authz
from fastapi import Depends, HTTPException
from jose import jwt, JWTError

SECRET_KEY = "loaded-from-environment-not-hardcoded"

def get_current_user(token: str = Depends(oauth2_scheme)) -> dict:
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        return {"user_id": payload["sub"], "roles": payload.get("roles", [])}
    except JWTError:
        raise HTTPException(status_code=401, detail="Invalid or expired token")

def require_role(role: str):
    def checker(user: dict = Depends(get_current_user)):
        if role not in user["roles"]:
            raise HTTPException(status_code=403, detail="Insufficient permissions")
        return user
    return checker

@app.delete("/orders/{order_id}")
def delete_order(order_id: int, user: dict = Depends(require_role("admin"))):
    orders_db.pop(order_id, None)
    return {"status": "deleted"}

This separation also makes audit logging cleaner: you can log every authorization decision independently of how the caller was authenticated, which matters when a compliance review asks who had access to what and when.

Rate Limit and Cache With Intention

Rate limiting protects your infrastructure from both abuse and honest mistakes, like a client stuck in a retry loop. Token bucket algorithms are the common choice because they allow short bursts while enforcing a steady average rate. Return rate-limit headers (X-RateLimit-Remaining, Retry-After) so well-behaved clients can back off gracefully instead of hammering a 429 response.

Caching deserves equal attention. REST's stateless nature makes HTTP caching (ETag, Cache-Control) nearly free to implement and dramatically reduces load for read-heavy endpoints. For GraphQL, where a single endpoint serves many different queries, caching is harder and usually requires persisted queries or a dedicated caching layer like a CDN-aware GraphQL gateway.

Design for Machine Consumption, Not Just Human Developers

A growing share of API traffic now comes from AI agents rather than humans reading documentation in a browser. Serving a machine-readable OpenAPI specification at a predictable path like /openapi.json, and keeping it in sync with the actual implementation through contract-driven codegen, lets both human developers and AI tooling integrate without guessing at behavior. Generating a plain-text summary file for agent consumption is also gaining traction, since it reduces the token overhead of parsing full HTML documentation pages.

The deeper principle here isn't new: documentation that drifts from the real API is worse than no documentation, because it actively misleads. Generating docs and client SDKs from the same source of truth as your route definitions is the only approach that scales past a handful of endpoints.

Handle Errors Like a First-Class Feature

A good error response tells the caller exactly what went wrong and what to do next. A vague 500 Internal Server Error forces the integrating developer to open a support ticket; a structured error body lets them fix it themselves.

// Consistent error shape across an Express API
app.use((err, req, res, next) => {
  const status = err.statusCode || 500;
  res.status(status).json({
    error: {
      code: err.code || 'INTERNAL_ERROR',
      message: err.message || 'Something went wrong',
      request_id: req.id,
    },
  });
});

Include a request ID in every error response and log it server-side. When a partner reports an issue, that ID turns a vague "it didn't work yesterday around 3 pm" into a five-second lookup in your logs.

Test the Contract, Not Just the Code

Unit tests verify your logic works. Contract tests verify your API still honors the promise made to consumers. Tools that validate requests and responses against your OpenAPI schema in CI catch a whole category of bugs — an accidentally renamed field, a type that quietly changed from string to integer — before they reach anyone outside your team.

# Simple schema validation test using pytest
import jsonschema

def test_order_response_matches_schema(client, order_schema):
    response = client.get("/orders/1")
    assert response.status_code == 200
    jsonschema.validate(instance=response.json(), schema=order_schema)

This is a cheap habit that pays for itself the first time it stops a breaking change from shipping on a Friday afternoon.

Bringing It Together

None of these practices are exotic. Resource-oriented design, cursor pagination, clean separation of authentication and authorization, contract testing, and machine-readable documentation are all well-understood techniques. What separates APIs that age well from the ones teams end up rewriting is consistency: applying these practices from the first endpoint rather than retrofitting them after the first outage or the first partner integration that broke silently.

If you're starting a new API today, resist the urge to optimize for the architecture you might need at scale. Start with REST and OpenAPI for anything public-facing, introduce gRPC only where you control both sides of a genuinely latency-sensitive call, and reach for GraphQL only when multiple clients demonstrably need different data shapes from the same resources. Build in versioning, rate limiting, and structured errors from day one — they're far cheaper to add now than to bolt on after your first integration partner depends on the old behavior.

Securing the Blockchain: A Deep Dive into Modern Encryption Protocols

Fuad Husnan — Wed, 02 Sep 2026 05:55:12 +0000

Blockchain encryption protocols are facing their first real stress test since Bitcoin's launch in 2009. For over a decade, the cryptographic assumptions underpinning nearly every major chain—elliptic curve signatures, SHA-256 hashing, RSA key exchange—held steady because no adversary had the computing power to break them. That assumption is now expiring. Researchers estimate that a sufficiently powerful quantum computer could compromise Bitcoin's signature scheme with far fewer qubits than previously thought, and regulators in the US and EU are already requiring critical infrastructure to migrate to post-quantum algorithms by 2030.

This article walks through how blockchain encryption actually works today, why it's vulnerable, and what protocols are replacing it. Along the way, we'll look at working code so the concepts aren't abstract.

How Blockchain Encryption Works Right Now

Every blockchain transaction depends on three cryptographic building blocks: hashing, asymmetric key pairs, and digital signatures. Hashing (usually SHA-256 or SHA-3) turns transaction data into a fixed-length fingerprint that changes completely if even one bit of input changes. Asymmetric cryptography gives each wallet a public key anyone can see and a private key only the owner holds. Digital signatures let a wallet prove it authorized a transaction without revealing the private key itself.

Here's a simplified version of how a transaction gets signed, using Python's cryptography library with ECDSA, the elliptic curve scheme Bitcoin and Ethereum both rely on:

from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric.utils import decode_dss_signature

# Generate a key pair using the secp256k1 curve (same curve as Bitcoin)
private_key = ec.generate_private_key(ec.SECP256K1())
public_key = private_key.public_key()

# Sign a transaction payload
transaction_data = b"send 0.5 BTC to address_xyz"
signature = private_key.sign(transaction_data, ec.ECDSA(hashes.SHA256()))

# Verify the signature using the public key
try:
    public_key.verify(signature, transaction_data, ec.ECDSA(hashes.SHA256()))
    print("Signature valid — transaction authorized")
except Exception:
    print("Signature invalid — reject transaction")

This works because factoring the elliptic curve discrete logarithm problem is computationally infeasible for classical computers. A private key derived from a 256-bit curve would take longer than the age of the universe to brute-force with current hardware. That's the whole security model: not unbreakable, just slow enough to break that nobody bothers.

Why Quantum Computing Changes the Math

Shor's algorithm, first published in 1997, gives a quantum computer a shortcut through exactly the kind of math ECDSA depends on. A classical computer needs exponential time to solve the elliptic curve discrete logarithm problem; a large enough quantum computer needs polynomial time. Any cryptographic protocol that relies on elliptic curves or RSA is vulnerable to Shor's algorithm, while hash functions like SHA-256 and SHA-3, along with symmetric encryption like AES, are expected to remain secure.

That distinction matters for prioritizing what to fix. Signature schemes and key exchange are exposed; hashing and symmetric encryption mostly are not, at least not to Shor's algorithm specifically. Grover's algorithm does give quantum computers a quadratic speedup against hash-based mining and brute-force search, but doubling the key or hash length restores most of the lost margin.

The more urgent risk isn't a quantum computer breaking Bitcoin tomorrow. It's what security researchers call "store now, decrypt later." Digital signatures typically used in blockchains are based on primitives vulnerable to quantum attacks—Bitcoin's elliptic curve scheme, for instance, could, by some optimistic estimates, be broken by a quantum computer as early as 2027. An adversary can harvest encrypted blockchain data and signed transactions now, then decrypt them once quantum hardware catches up. For any asset or credential meant to stay confidential for years, that clock is already running.

Post-Quantum Cryptography: The Leading Candidates

The National Institute of Standards and Technology has spent years running a public competition to standardize post-quantum cryptographic (PQC) algorithms, and a handful have emerged as the practical front-runners for blockchain use.

Lattice-based schemes, particularly CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium for signatures, currently offer the best balance of security and performance. Lattice-based schemes such as Kyber and NTRU provide high resistance at practical key sizes, though they can be slower to verify transactions and have lower throughput than classical schemes. Hash-based signature schemes like SPHINCS+ trade some of that performance for stronger, more conservative security guarantees, since their safety rests entirely on well-understood hash function properties rather than newer lattice assumptions.

Here's what a Kyber-style key encapsulation exchange looks like conceptually, using the pqcrypto Python bindings as an example of the API shape (actual production use requires vetted, audited libraries):

from pqcrypto.kem.kyber768 import generate_keypair, encrypt, decrypt

# Node A generates a post-quantum key pair
public_key, secret_key = generate_keypair()

# Node B uses the public key to create a shared secret and ciphertext
ciphertext, shared_secret_b = encrypt(public_key)

# Node A decrypts the ciphertext to recover the same shared secret
shared_secret_a = decrypt(secret_key, ciphertext)

assert shared_secret_a == shared_secret_b
print("Shared secret established without exposing the private key")

The mechanics differ from ECDH under the hood, but the goal is identical: two parties agree on a shared secret over an insecure channel without a quantum-capable eavesdropper being able to reconstruct it from the exchange.

Migration Strategies Chains Are Actually Using

No major chain can flip a switch and swap its signature scheme overnight without breaking every wallet and smart contract built on top of it. Three migration patterns have emerged in practice.

Hybrid signing runs classical and post-quantum signatures side by side during a transition window, so a transaction is only valid if both signatures check out. This buys time without abandoning battle-tested classical cryptography before PQC schemes have equivalent real-world track records. Some networks may employ hard forks to introduce PQC-based transaction formats for all future transactions, while others adopt hybrid models supporting both classical and PQC signatures during the migration period, reducing disruption to existing users.

Commit-delay-reveal protocols address the specific problem of migrating already-exposed public keys. The protocol operates in three phases: the user commits a hash linking the existing public key with a quantum-resistant public key without revealing either; then funds remain locked for a security period to prevent quantum attackers from exploiting exposed keys, before the new key is finally revealed. This closes the gap between "vulnerable key visible on-chain" and "safe key active," which matters because public keys used in earlier transactions are often exposed on-chain and thus permanently harvestable.

New consensus-layer research is also underway to move validator selection and threshold signing itself onto quantum-resistant foundations. Proposed solutions include threshold signatures combined with post-quantum cryptography, lattice-based verifiable random functions for validator selection, and hybrid consensus protocols that combine quantum-resilient primitives, though trade-offs in throughput and decentralization at scale are still being quantified.

Zero-Knowledge Proofs Need Their Own Upgrade Path

Zero-knowledge rollups and privacy chains rely on cryptographic proof systems that have their own quantum exposure, separate from wallet signatures. Blockchains will need to use newer STARK and SNARG zero-knowledge systems that are quantum-resistant, at the cost of larger proofs and longer verification times, and networks like Starknet are already transitioning to the FRI protocol to get there. This is a useful reminder that "quantum-resistant blockchain" isn't a single upgrade — it touches signatures, key exchange, hashing assumptions, and proof systems separately, each on its own migration timeline.

What Developers Can Do Today

Waiting for a chain-wide hard fork isn't the only lever available to teams building on blockchain infrastructure right now. A few practical steps reduce exposure well before any mandatory migration deadline.

Auditing which cryptographic primitives a given application actually depends on is the starting point — most teams have never mapped which of their signing, hashing, and key-exchange calls touch vulnerable elliptic curve or RSA operations versus quantum-safe hash functions. Layering hybrid encryption into any new infrastructure, even before a chain formally requires it, limits future rework. TLS 1.3 already ships production-ready post-quantum key exchange support, and major providers like Google and AWS are quietly migrating their own services to it, which is a reasonable signal that the tooling has matured past the experimental stage.

For anything storing long-lived sensitive data on-chain or in transit, treating "store now, decrypt later" as an active threat today — not a 2030 problem — is the more conservative and arguably correct posture, given how far encrypted data can be harvested and how permanently it sits exposed once captured.

Where This Leaves the Industry

The transition to post-quantum blockchain security won't happen through a single dramatic event. It's already underway in fragments: hybrid signature schemes in production, NIST-approved algorithms shipping in mainnets, TLS infrastructure quietly upgrading in the background, and academic research narrowing the remaining trade-offs between security, throughput, and decentralization. The chains and applications that treat this as a multi-year engineering migration — auditing dependencies, adopting hybrid models early, and tracking NIST standardization — will be in a materially better position than those waiting for a forcing event that, by definition, arrives without warning.

The underlying lesson extends past cryptocurrency. Any system relying on RSA or elliptic curve cryptography for long-term security, not just blockchains, faces the same migration pressure on a similar timeline.

How End-to-End Encryption Protects Private Crypto Keys

Fuad Husnan — Wed, 02 Sep 2026 05:52:10 +0000

Plaintext key  →  AES-256-GCM encryption  →  Ciphertext stored/transmitted
     ↑                                              ↓
 Only exists in                              Unreadable without
 memory on device                            the decryption key

That's the entire point of end-to-end encryption applied to private keys: the raw key material never travels in a form anyone else can read, not even the service relaying it. For anyone managing cryptocurrency wallets, understanding how end-to-end encryption protects private keys is the difference between owning your assets and trusting someone else's server not to get breached.

Private keys are the single point of failure in crypto custody. Whoever holds the key controls the funds, full stop. End-to-end encryption (E2EE) doesn't eliminate that risk, but it narrows the attack surface dramatically by making sure the key is encrypted before it leaves the device that generated it, and stays encrypted until it's decrypted on another device the user controls.

What End-to-End Encryption Actually Means for Keys

End-to-end encryption is often used loosely, so it's worth being precise. In a properly implemented E2EE system, encryption and decryption happen only at the endpoints. Any server, relay, or cloud backup sitting in between only ever sees ciphertext.

Applied to a private key, this means the key is encrypted locally, typically with a symmetric cipher like AES-256-GCM, using a key derived from something the user controls, such as a password or biometric-unlocked secure enclave. The encrypted blob can then be backed up to a cloud service, synced across devices, or sent through a wallet provider's infrastructure without exposing the underlying key.

Here's a simplified example of how a private key gets encrypted before storage, using Python's cryptography library:

from cryptography.hazmat.primitives.ciphersaead import AESGCM
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives import hashes
import os

def derive_key(password: bytes, salt: bytes) -> bytes:
    kdf = PBKDF2HMAC(
        algorithm=hashes.SHA256(),
        length=32,
        salt=salt,
        iterations=600_000,
    )
    return kdf.derive(password)

def encrypt_private_key(private_key: bytes, password: bytes) -> dict:
    salt = os.urandom(16)
    nonce = os.urandom(12)
    encryption_key = derive_key(password, salt)
    aesgcm = AESGCM(encryption_key)
    ciphertext = aesgcm.encrypt(nonce, private_key, None)
    return {
        "ciphertext": ciphertext,
        "salt": salt,
        "nonce": nonce,
    }

The password never leaves the device either. It's run through a key derivation function (PBKDF2 here, though Argon2 is increasingly preferred for its memory-hardness) to produce the actual encryption key. This means even if the ciphertext, salt, and nonce are all intercepted, an attacker still has to brute-force the password to recover the private key.

Why This Matters More for Crypto Than Other Data

Most data breaches are recoverable. A leaked password can be reset. A stolen credit card can be canceled. A leaked private key cannot be revoked once funds have moved. There's no customer support line for a blockchain.

That asymmetry is why wallet providers and custody platforms treat key encryption differently from ordinary application security. A non-custodial wallet's entire value proposition rests on the claim that the provider itself cannot access user funds, which only holds if the private key is encrypted before it ever touches the provider's servers.

This is also why the industry has moved toward multi-party computation (MPC) as a complement to, and in some cases a replacement for, single-key encryption. Instead of encrypting one complete private key, MPC splits key material into multiple shares held by different parties, none of which ever reconstructs the full key during signing. Recent wallet security comparisons note that multi-party computation divides a private key into multiple encrypted parts stored separately, removing the need for a single recovery phrase and reducing hacking risk. E2EE and MPC solve overlapping but distinct problems: E2EE protects a key in transit and at rest, while MPC avoids ever having a single, complete key to protect in the first place.

Where Encryption Alone Falls Short

End-to-end encryption protects data in transit and in storage, but it says nothing about what happens on the endpoint itself. If a device is compromised by malware, or if the user is tricked into approving a malicious transaction, E2EE offers no protection because the attacker is operating at the point where the key is legitimately decrypted for use.

This is a real and current gap. Wikipedia's overview of the technology notes that even in a correctly implemented E2EE system, data may be held unencrypted on the user's own device or accessed through their own app if their credentials are compromised. For crypto wallets specifically, that translates into phishing attacks that trick users into signing malicious transactions, clipboard-hijacking malware that swaps a copied wallet address for an attacker's address, and fake wallet apps that request seed phrase input directly.

Hardware wallets exist largely to close this endpoint gap. By keeping the private key inside a dedicated secure element chip that never exposes raw key material to the connected computer or phone, they add a hardware boundary on top of software encryption. Industry guides describe how leading devices rely on a Secure Element chip with Common Criteria EAL6+ certification that encrypts all data stored on the chip, which is a meaningfully higher bar than software-only encryption running on a general-purpose operating system.

Encryption in Transit vs. Encryption at Rest

It's worth separating two things that often get bundled under the "E2EE" label: protecting a key while it moves between devices, and protecting a key while it sits in storage.

In transit, the concern is a man-in-the-middle attack intercepting a key as it syncs between a phone and a desktop wallet, or as it's transmitted during wallet recovery. TLS handles the transport layer, but a properly E2EE system doesn't rely on transport security alone. It encrypts the key payload itself, so that even a compromised or malicious relay server can't read it.

At rest, the concern is a breached database or a stolen device. A wallet provider's servers getting hacked should be a non-event for user funds if every stored key blob is ciphertext derived from a user-held secret. This is the guarantee non-custodial and self-custody products are built around: in non-custodial wallets, you control your private keys directly, and the provider's infrastructure never holds anything usable on its own.

Here's a minimal illustration of verifying that a stored key blob is genuinely unreadable without the user's password, using authenticated decryption to detect tampering:

def decrypt_private_key(encrypted_data: dict, password: bytes) -> bytes:
    encryption_key = derive_key(password, encrypted_data["salt"])
    aesgcm = AESGCM(encryption_key)
    try:
        return aesgcm.decrypt(
            encrypted_data["nonce"],
            encrypted_data["ciphertext"],
            None,
        )
    except Exception:
        # AEAD authentication failure: wrong password or tampered ciphertext
        raise ValueError("Decryption failed — key may be corrupted or password incorrect")

The use of an AEAD (authenticated encryption with associated data) cipher like AES-GCM matters here specifically because it detects tampering. If an attacker modifies even a single byte of the ciphertext, decryption fails loudly rather than silently returning corrupted key material.

Cold Storage as the Practical Endpoint of This Model

Cold wallets take the E2EE principle to its logical extreme by removing network connectivity from the equation entirely. A cold wallet keeps private keys completely offline, isolated from internet connectivity and potential cyber threats, which means there's no transit leg to encrypt in the first place because the key never leaves an air-gapped device.

This is why serious long-term holdings tend to migrate toward hardware and cold storage rather than relying on software encryption alone. Encryption protects data that has to move or be stored somewhere accessible; air-gapping avoids the need for that movement altogether. The two approaches aren't competing so much as addressing different parts of the same threat model, and most security-conscious setups combine both: an encrypted software wallet for everyday transactions, and cold storage for the bulk of long-term holdings.

The Trade-Offs Nobody Advertises

Strong encryption comes with a real cost: if the user loses the password or key derivation secret, the encrypted key is unrecoverable. There's no backdoor, because a backdoor would defeat the entire purpose. This is precisely why seed phrases exist as a separate recovery mechanism, and why losing both a password and a seed phrase means permanent loss of funds.

There's also a policy dimension worth naming honestly. End-to-end encryption in consumer products has become genuinely contested outside of crypto specifically. In one prominent case, Meta ended support for end-to-end encryption on Messenger in May 2026, justified as a measure to mitigate fraudulent activity and facilitate detection of harmful content, a move that child protection organizations supported while privacy advocates argued it compromises user security. Crypto wallets sit further from that particular debate since there's no messaging content to moderate, but the underlying tension between strong encryption and third-party oversight isn't unique to messaging apps, and it's reasonable to expect similar pressure on custody platforms as regulatory scrutiny of crypto increases.

What This Means for Choosing a Wallet

Not every product marketed as "encrypted" implements E2EE correctly. The meaningful question to ask any wallet provider is not whether they encrypt data, but whether they can decrypt user funds themselves. If the answer is yes, under any circumstance, including a subpoena or a rogue employee, then encryption is happening somewhere other than the endpoint, and the E2EE label is being used loosely.

Infrastructure providers building wallet tooling now describe this explicitly as a design requirement rather than a feature. Wallet infrastructure platforms increasingly advertise end-to-end private key generation, encryption, and access control within secure enclaves, built to be fully non-custodial so the provider itself has no access to user assets. That's the standard worth holding any wallet to, whether it's a consumer app or backend infrastructure a business is integrating.

For anyone managing meaningful crypto holdings, the practical takeaway is straightforward. Use a wallet where key encryption happens on-device, verify the provider genuinely cannot decrypt your keys, treat hardware wallets as the default for anything beyond spending money, and never let a password or seed phrase exist in a place an attacker could realistically reach. Encryption is only as strong as the weakest point where a key briefly exists in plaintext, and that point should always be a device only you control.

How Quantum Computing Threats Are Reshaping Cryptocurrency Security

Fuad Husnan — Wed, 02 Sep 2026 05:48:55 +0000

Roughly 5.4 million bitcoin, worth hundreds of billions of dollars, sits in wallets whose public keys have already been exposed on-chain. Quantum computing is the reason that number matters. Once a sufficiently powerful quantum computer exists, exposed public keys stop being harmless strings of data and become the starting point for stealing funds outright, which is why cryptocurrency security is now being redesigned years before that computer is built.

The threat isn't hypothetical hand-waving about far-off science fiction. NIST, IBM, Google, and PsiQuantum have each published timelines that converge on the 2030-to-2035 window for cryptographically relevant quantum computers. Blockchain protocols built on elliptic curve cryptography have to migrate before that window closes, not after, because the migration itself takes years and the assets at risk can't simply be recalled once the threat materializes.

Why Elliptic Curve Cryptography Breaks Under Quantum Attack

Bitcoin, Ethereum, and most major cryptocurrencies rely on the Elliptic Curve Digital Signature Algorithm (ECDSA) to prove ownership of funds. The security of ECDSA rests on the elliptic curve discrete logarithm problem: given a public key, it's computationally infeasible for classical computers to derive the corresponding private key. That infeasibility is the entire basis of the trust model.

Shor's algorithm changes the math. Running on a fault-tolerant quantum computer, it solves the discrete logarithm problem in polynomial time instead of the exponential time classical computers require. A 2025 analysis from Google Quantum AI researcher Craig Gidney estimated that factoring a 2048-bit RSA key would require under a million noisy qubits, a dramatic reduction from earlier estimates that assumed tens of millions. Applied to elliptic curve keys, similar resource reductions mean the timeline for a practical break keeps compressing rather than expanding.

# Simplified illustration of what ECDSA relies on:
# given P = k * G (public key = private key * generator point),
# recovering k classically is intractable.
# Shor's algorithm solves this class of problem efficiently on
# a fault-tolerant quantum computer, which is why exposed public
# keys — not just private keys — become the attack surface.

def is_public_key_exposed(address_type: str, has_been_spent: bool) -> bool:
    """
    Returns True if the public key for this address is already
    visible on-chain and therefore quantum-attackable once a
    cryptographically relevant quantum computer exists.
    """
    always_exposed = {"P2PK", "P2TR"}  # public key visible by design
    if address_type in always_exposed:
        return True
    # P2PKH, P2WPKH, P2WSH hide the key behind a hash until spent
    return has_been_spent

This is why the risk isn't evenly distributed across a blockchain. Coins sitting in never-spent hashed addresses, like standard P2PKH or SegWit outputs, keep their public key hidden until the moment they're spent. Coins in P2PK addresses or reused P2PKH addresses have already broadcast their public key, which means they're exposed today and simply waiting for the hardware to catch up.

The Scale of Bitcoin's Exposure Is Larger Than Most Holders Realize

Multiple independent chain analyses have tried to quantify exactly how much Bitcoin sits in this exposed category, and the estimates have grown as measurement techniques improved. Deloitte's earlier scans put the figure at roughly 25% of circulating supply. More recent 2026 measurements from Glassnode found 6.04 million BTC, about 30.2% of issued supply and worth roughly $469 billion, with exposed public keys on-chain.

That figure splits into meaningfully different risk categories. Around 2.3 million BTC, roughly 12% of supply, is dormant across every address type, including Satoshi-era coins whose owners can never move them to safety even with warning. Another 3.7 million BTC, about 19% of supply, is exposed but still spendable, meaning owners can sweep those funds into quantum-resistant outputs if they act before a quantum computer arrives. The remaining 65 to 70% of supply sits in fresh, never-reused hashed addresses, where the public key is only briefly revealed at the moment of spending.

Ethereum's exposure looks structurally different. Because Ethereum was designed around persistent, reused addresses rather than one-time hashed outputs, a much larger share of its supply has already broadcast its public keys as a normal consequence of everyday use. That design choice, which made Ethereum more usable for smart contracts, also makes the network's quantum migration path more urgent and more complicated than Bitcoin's.

The "Harvest Now, Decrypt Later" Problem Compounds the Risk

Even setting aside live quantum attacks on a currently exposed key, cryptocurrency networks face a subtler threat: adversaries can record and store today's exposed public keys and transaction data now, with the explicit plan of decrypting them once quantum hardware matures. Security researchers call this Harvest Now, Decrypt Later, or HNDL, and it applies to blockchains just as it applies to encrypted government communications and corporate data.

For a bank record or a diplomatic cable, HNDL means confidentiality fails years later. For a cryptocurrency wallet, it's more direct: an adversary who has already harvested a public key doesn't need to break anything new when the quantum computer arrives. They just need to run the attack and move the funds before the legitimate owner does. This is one reason security researchers argue the migration clock started the moment Shor's algorithm was proven, not the moment a quantum computer capable of running it gets built.

There's also a narrower, more time-sensitive exposure window that applies to every Bitcoin transaction, regardless of address type. When a transaction is broadcast, its public key becomes visible in the mempool before the transaction is confirmed on-chain. Confirmation currently takes around ten minutes. A sufficiently fast quantum attacker could theoretically intercept that window, derive the private key, and submit a competing transaction with a higher fee, a scenario sometimes called a transaction hijack or race attack. This is a distinct risk from address-level exposure because it threatens every future transaction, not just historically reused ones.

Where Post-Quantum Standards Currently Stand

NIST finalized its first three post-quantum cryptography standards in August 2024: ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (formerly SPHINCS+) as a hash-based signature backup. A fourth algorithm, HQC, was added in 2025 to diversify the mathematical assumptions the standards rely on, reducing the risk that a single cryptanalytic breakthrough compromises everything at once.

That diversification turned out to matter quickly. In July 2026, Anthropic disclosed that an AI model it developed had discovered a vulnerability in HAWK, a lattice-based signature algorithm that was under consideration for standardization. The HAWK team withdrew the algorithm, and NIST confirmed the finding doesn't affect the already-finalized ML-KEM or ML-DSA standards, which rest on different mathematical foundations. The episode is a useful reminder that post-quantum cryptography is still an active research field, not a solved problem with a single fixed answer, and that crypto-agility, meaning the ability to swap algorithms without rebuilding a system from scratch, is as important as picking the right algorithm today.

# Conceptual sketch of a hybrid signature scheme, combining a
# classical and post-quantum algorithm so that breaking either
# one alone is insufficient to forge a valid signature.

def hybrid_sign(message: bytes, ecdsa_key, dilithium_key) -> dict:
    classical_sig = ecdsa_sign(message, ecdsa_key)
    pq_sig = dilithium_sign(message, dilithium_key)
    return {
        "message": message,
        "ecdsa_signature": classical_sig,
        "ml_dsa_signature": pq_sig,
    }

def hybrid_verify(signed: dict, ecdsa_pub, dilithium_pub) -> bool:
    return (
        ecdsa_verify(signed["message"], signed["ecdsa_signature"], ecdsa_pub)
        and ml_dsa_verify(signed["message"], signed["ml_dsa_signature"], dilithium_pub)
    )

NIST's IR 8547 sets a broader migration timeline: quantum-vulnerable algorithms should be deprecated by 2030 and removed from standards entirely by 2035, with high-risk systems expected to transition earlier. That timeline was written with government and enterprise systems in mind, but it's become a reference point for blockchain governance discussions as well, since cryptocurrency networks face the same underlying hardware timeline without the benefit of centralized rollout authority.

How Blockchain Networks Are Actually Responding

Bitcoin and Ethereum face the migration problem differently because their governance models differ. Bitcoin's protocol changes require broad consensus among node operators, miners, and businesses, which makes any hard fork slow by design. BIP-360 is the primary proposal addressing quantum resistance, aiming to introduce a new address format that supports post-quantum signature schemes such as hash-based signatures, without requiring every wallet to migrate simultaneously.

Ethereum's public roadmap treats quantum resistance as a defined workstream rather than a distant contingency. The Ethereum Foundation's post-quantum team has been developing proposals, including EIP-8141, drafted in January 2026, which explores account abstraction mechanisms that could allow wallets to adopt quantum-resistant signature schemes without requiring every user to generate an entirely new address from scratch. Because Ethereum already relies heavily on account abstraction infrastructure from EIP-7702, that flexibility gives it a somewhat smoother migration path than Bitcoin's UTXO model, even though its baseline exposure is higher.

Smaller ecosystems are moving faster precisely because they carry less legacy weight. Postquant Labs launched Quip Network in April 2026, a Layer 2 Bitcoin wallet built on WOTS+ (Winternitz One-Time Signature) cryptography, running through the Arch Network smart contract layer. It's a narrower, opt-in solution rather than a base-layer protocol change, but it illustrates the kind of incremental migration path that doesn't require waiting on Bitcoin Core consensus.

# Example: checking whether a Bitcoin UTXO is in the
# "migratable but currently exposed" risk tier, combining
# address type and spend history the way chain analyses do.

def classify_exposure(address_type: str, spend_count: int, is_dormant: bool) -> str:
    if is_dormant and address_type in {"P2PK"}:
        return "irreducible"          # owner can no longer act
    if address_type in {"P2PK", "P2TR"} or spend_count > 0:
        return "migratable_exposed"   # owner can still sweep funds
    return "protected"                # key hidden until first spend

# Wallet software increasingly flags "migratable_exposed" UTXOs
# so holders can proactively move funds to fresh addresses ahead
# of any quantum-capable adversary.

What This Means for Developers and Holders Right Now

For developers building on top of these chains, the practical starting point is crypto-agility: designing signature verification and key management so that a new algorithm can be added without a full rewrite. Hard-coding ECDSA assumptions throughout a codebase creates exactly the kind of migration debt that will be expensive to unwind later. Libraries like OpenSSL, BoringSSL, and Bouncy Castle have already begun adding support for ML-KEM and ML-DSA, giving teams a path to start experimenting with hybrid classical-plus-post-quantum schemes now, well before any hard deadline forces the issue.

For individual holders, the practical guidance follows directly from the exposure tiers Deloitte, Glassnode, and other chain analyses have mapped out. Funds sitting in a never-reused address carry structurally lower risk than funds in a reused P2PKH address or an old P2PK output, and wallet software is beginning to surface that distinction directly rather than leaving users to interpret raw address formats themselves. Avoiding address reuse, a piece of advice that predates the quantum conversation entirely, turns out to double as quantum hygiene.

None of this means a quantum attack is imminent. Every credible timeline still places a cryptographically relevant quantum computer somewhere in the 2030 to 2035 range, and the HAWK withdrawal is a reminder that even the replacement algorithms are still being stress-tested. But the migration work, in protocol design, in wallet software, and in developer tooling, takes years to roll out safely across a decentralized network with no central authority to force an upgrade. The organizations and protocols treating this as a 2026 problem rather than a 2032 problem are the ones setting the standard the rest of the ecosystem will eventually have to follow.

Keeping Your Smart Devices Safe from Hackers

Fuad Husnan — Sun, 23 Aug 2026 05:50:36 +0000

Smart devices are no longer a novelty confined to tech enthusiasts' living rooms. From thermostats and doorbell cameras to voice assistants and connected light bulbs, the average household now runs a small network of internet-connected gadgets around the clock. That convenience comes with a cost: connected households face nearly 30 IoT attack attempts every single day, according to a 2025 report from Netgear and Bitdefender that analyzed data from 6.1 million households. Keeping smart devices safe from hackers is no longer optional homework for IT professionals — it's a basic requirement for anyone who owns a smart speaker, camera, or lock.

The good news is that most successful attacks on smart homes don't involve sophisticated exploits or nation-state hackers. They rely on the same handful of weaknesses: default passwords, outdated firmware, and networks with no internal boundaries. Understanding those weaknesses, and closing them, is well within reach for a non-technical homeowner.

Why Smart Devices Are Such an Easy Target

Manufacturers competing on price and speed to market often treat security as an afterthought. Many devices still ship with generic default credentials such as "admin" or "1234," and a large share of buyers never bother to change them. Attackers know this, and they maintain databases of default logins for thousands of device models, which lets them scan the internet and break into unsecured devices within seconds.

The scale of the problem is easy to underestimate until you see it measured. A Which? investigation, run in partnership with the NCC Group and the Global Cyber Alliance, filled a test home with ordinary smart devices — TVs, thermostats, and security systems — and logged the incoming traffic. In a single week, the home was hit with over 12,800 unique scans and hack attempts, including more than 2,400 login attempts using weak default usernames and passwords. That's roughly 14 credential-stuffing attempts every hour, aimed at a house with nothing more exotic than a smart TV and a few sensors.

Streaming devices and smart TVs are consistently among the most exposed categories, together accounting for close to half of all detected security flaws in connected homes, with IP cameras not far behind. These devices tend to run outdated software, get fewer security updates than phones or laptops, and are rarely monitored the way a work computer would be.

The Real-World Consequences of a Compromised Device

It's tempting to think of a hacked smart bulb or thermostat as a minor inconvenience. In practice, a single compromised device can become a foothold into the rest of your home network, exposing laptops, phones, and any files or accounts connected to them.

The most infamous example remains the 2016 Mirai botnet attack, in which hundreds of thousands of poorly secured devices, including doorbell cameras, were hijacked and used to launch massive distributed denial-of-service attacks that knocked major websites offline. That single incident demonstrated how a garage full of smart plugs and cameras could be conscripted, without their owners' knowledge, into one of the largest cyberattacks in internet history.

More recent incidents have moved beyond botnets and into direct surveillance. Security researchers have documented cases where compromised smart cameras allowed strangers to watch a family's daily routine for weeks, using nothing more advanced than a default password that was never changed after setup. Camera feeds, door lock activity, and even microphone access on voice assistants represent some of the most sensitive data a device can leak, which is why cameras and locks deserve the most scrutiny of any device category in the home.

Start With Your Router, Not Your Gadgets

Every smart device conversation tends to start with the devices themselves, but the router is the actual front door to your network, and it deserves attention first. Change the router's default admin password immediately after setup, since this credential controls every other device on the network. Enable WPA3 encryption if your router supports it, or WPA2 at a minimum, and retire the factory-set Wi-Fi password that often ships printed on the bottom of the device.

Network segmentation is one of the more effective, if underused, protections available to ordinary households. Most modern routers support a guest network feature that can be repurposed to isolate IoT devices from the primary network used by computers and phones. If a smart plug or camera on the guest network is compromised, the attacker is contained there rather than gaining a path to your laptop, banking apps, or personal files. Security researchers and IoT security guides consistently point to this kind of network isolation, alongside strong authentication, as one of the most practical defenses against exactly this kind of lateral movement.

Firmware Updates Are Not Optional

Roughly 70% of connected devices in circulation carry unpatched firmware vulnerabilities, according to IoT security research compiled from multiple threat intelligence sources. Firmware is the software that runs a device at the most basic level, and manufacturers regularly release updates to patch newly discovered security holes. Unlike a phone, though, most smart devices don't nag you with update reminders, which means outdated firmware quietly accumulates unless a homeowner goes looking for it.

Set a recurring reminder, perhaps quarterly, to check each device's companion app or web interface for pending firmware updates. Many current-generation devices support automatic updates, and turning that setting on removes the burden of remembering entirely. When shopping for new smart devices, treat a manufacturer's update track record as a genuine buying criterion rather than an afterthought; a camera that's cheaper but hasn't received a security patch in two years is not actually the better deal.

Passwords, Two-Factor Authentication, and the Human Factor

Default credentials remain the single most exploited weakness in smart home security, and the fix is straightforward even if it's tedious. Every device should get a unique password rather than a variation on the same phrase, and a password manager makes this realistic for a household running fifteen or twenty connected gadgets rather than the two or three of a decade ago.

Two-factor authentication, where available, blocks the overwhelming majority of unauthorized login attempts even when a password has been guessed or leaked elsewhere. Voice assistants, smart lock apps, and camera platforms increasingly support this option, and enabling it takes a few minutes per account. It's one of the highest-leverage security steps available, precisely because it protects you even after a mistake has already happened elsewhere, such as reusing a password that later turns up in a data breach.

Choosing Devices With Security in Mind

Not every smart device deserves a place on your network. Emerging standards like Matter aim to create more consistent security baselines across brands, and devices built to that standard are generally a safer bet than obscure, ultra-cheap alternatives with no clear manufacturer support. Before buying, it's worth checking whether a company has a documented history of shipping timely security patches, since that pattern tends to predict how the device will be maintained after you bring it home rather than how it's marketed in the box.

It also helps to be deliberate about which devices actually need internet connectivity. A smart lock or camera has an obvious reason to be online; a coffee maker's connected features are harder to justify against the added attack surface. Limiting the number of connected devices in a household is itself a form of protection, since fewer devices mean fewer potential entry points for an attacker to probe.

A Realistic Way to Think About the Risk

It's worth resisting both extremes here. Headlines about mass camera hacks can make smart home ownership feel reckless, but security researchers who study these incidents note that most breaches trace back to weak passwords or someone the victim already knew, not sophisticated strangers deploying advanced tools. At the same time, dismissing the risk entirely ignores a household network that, on average, now fields close to 30 attack attempts a day.

The practical takeaway sits between panic and complacency: smart devices are safe enough to use, provided the basic hygiene outlined above is actually in place. A secured router, segmented network, current firmware, and unique passwords with two-factor authentication turn a smart home from an easy target into a genuinely difficult one, without requiring a background in cybersecurity to get there.

Take an inventory of every connected device in your home this week, check each one for a default password or a pending firmware update, and fix what you find. That single afternoon of maintenance addresses the majority of what actually gets exploited in the real world, and it's a far better use of time than worrying about threats that are, statistically, much less common than the mundane ones sitting unpatched on your own network right now.

Tracking Heart Health with Wearable IoT Sensors

Fuad Husnan — Sun, 23 Aug 2026 05:49:12 +0000

Tracking heart health with wearable IoT sensors has moved from a niche research exercise to something a consumer smartwatch does before breakfast. A photoplethysmography sensor no bigger than a fingernail can now estimate heart rate, detect irregular rhythms, and flag potential atrial fibrillation, all while sipping power from a coin-cell-sized battery. That shift didn't happen because sensors got smarter on their own. It happened because the surrounding system — signal processing, connectivity, and cloud pipelines — matured enough to turn noisy raw data into something a doctor or a user can actually trust.

This article walks through how these systems work in practice: the sensor hardware, the firmware that cleans up the signal, the protocols that move data off the wrist, and the backend code that turns a stream of numbers into a heart rate you can act on.

How Wearable Heart Sensors Actually Measure Your Pulse

Most consumer wearables rely on photoplethysmography, or PPG, rather than the electrocardiogram electrodes used in clinical settings. A PPG sensor shines light — usually green LEDs for wrist-worn devices — into the skin and measures how much of it bounces back. Blood volume in the capillaries changes with each heartbeat, which changes how much light is absorbed. The result is a waveform that rises and falls with the cardiac cycle.

The tricky part isn't detecting the waveform. It's detecting it while the wearer is walking, typing, or lifting weights. Motion artifacts can swamp the actual pulse signal, which is why most modern wearables pair the PPG sensor with an accelerometer. The accelerometer data is used to identify and subtract motion-related noise before the heart rate is calculated, a technique often called motion artifact cancellation.

Some higher-end devices, including several current smartwatches and dedicated chest straps, add a single-lead ECG sensor for spot checks. ECG measures the heart's electrical activity directly rather than inferring it from blood flow, which makes it more accurate for detecting irregular rhythms, though it typically requires the user to hold two fingers on the device to complete the electrical circuit, so it isn't continuous the way PPG is.

Reading Raw Sensor Data on an IoT Device

On the firmware side, most PPG modules — the MAX30102 is a common example in hobbyist and prototype projects — communicate over I2C and return raw infrared and red LED readings that need to be filtered before they resemble a heartbeat.

#include <Wire.h>
#include "MAX30105.h"
#include "heartRate.h"

MAX30105 particleSensor;

const byte RATE_SIZE = 4;
byte rates[RATE_SIZE];
byte rateSpot = 0;
long lastBeat = 0;
float beatsPerMinute;
int beatAvg;

void setup() {
  Serial.begin(115200);
  Wire.begin();

  if (!particleSensor.begin(Wire, I2C_SPEED_FAST)) {
    Serial.println("MAX30102 not found. Check wiring.");
    while (1);
  }

  particleSensor.setup();
  particleSensor.setPulseAmplitudeRed(0x0A);
  particleSensor.setPulseAmplitudeGreen(0);
}

void loop() {
  long irValue = particleSensor.getIR();

  if (checkForBeat(irValue)) {
    long delta = millis() - lastBeat;
    lastBeat = millis();
    beatsPerMinute = 60 / (delta / 1000.0);

    if (beatsPerMinute < 255 && beatsPerMinute > 20) {
      rates[rateSpot++] = (byte)beatsPerMinute;
      rateSpot %= RATE_SIZE;

      beatAvg = 0;
      for (byte x = 0; x < RATE_SIZE; x++) beatAvg += rates[x];
      beatAvg /= RATE_SIZE;
    }
  }

  if (irValue < 50000) {
    Serial.println("No finger detected");
  } else {
    Serial.print("BPM: ");
    Serial.println(beatAvg);
  }
}

This kind of code sits at the edge of the system, on the microcontroller itself. It handles peak detection and a rolling average, but it doesn't do anything with the data beyond printing it to a serial console. In a real product, that BPM value needs to travel somewhere: a phone app, a cloud dashboard, or a clinician's monitoring system. That's where connectivity choices start to matter.

Getting Data Off the Device: BLE, Wi-Fi, and Cellular

Bluetooth Low Energy is the default choice for wrist-worn and chest-strap heart monitors because it's built for exactly this use case: small, infrequent bursts of data from a battery-constrained device to a nearby phone. The Bluetooth SIG even standardized a Heart Rate Service profile, so a compliant BLE heart rate monitor can be read by any compatible app without custom pairing logic.

import asyncio
from bleak import BleakScanner, BleakClient

HEART_RATE_UUID = "00002a37-0000-1000-8000-00805f9b34fb"

def parse_heart_rate(data: bytearray) -> int:
    flags = data[0]
    if flags & 0x01:
        return int.from_bytes(data[1:3], byteorder="little")
    return data[1]

def handle_notification(sender, data: bytearray):
    bpm = parse_heart_rate(data)
    print(f"Heart rate: {bpm} bpm")

async def monitor_heart_rate():
    devices = await BleakScanner.discover()
    target = next((d for d in devices if d.name and "HRM" in d.name), None)

    if not target:
        print("No heart rate monitor found nearby.")
        return

    async with BleakClient(target.address) as client:
        await client.start_notify(HEART_RATE_UUID, handle_notification)
        await asyncio.sleep(60)
        await client.stop_notify(HEART_RATE_UUID)

asyncio.run(monitor_heart_rate())

For devices that need to report continuously without a phone in range — think remote patient monitoring for cardiac rehab patients — cellular options like LTE-M or NB-IoT trade higher power consumption for independence from a paired smartphone. Wi-Fi shows up in fitness equipment and home health hubs but rarely in the wearable itself, since it drains battery far faster than BLE for the same amount of data.

Turning Sensor Streams into Something Clinically Useful

Raw BPM numbers are a start, but heart health tracking becomes genuinely useful once the data is aggregated, contextualized, and checked against patterns over time. A single elevated reading during a workout means nothing. A resting heart rate that's crept up 15 beats per minute over three weeks is worth a second look.

This is typically handled server-side, once data lands in a time-series database or a managed IoT platform.

from fastapi import FastAPI
from pydantic import BaseModel
from datetime import datetime
import statistics

app = FastAPI()

class HeartRateReading(BaseModel):
    device_id: str
    bpm: int
    timestamp: datetime
    resting: bool = False

readings_db: dict[str, list[HeartRateReading]] = {}

@app.post("/readings")
async def ingest_reading(reading: HeartRateReading):
    readings_db.setdefault(reading.device_id, []).append(reading)
    return {"status": "recorded"}

@app.get("/devices/{device_id}/resting-trend")
async def resting_trend(device_id: str, days: int = 14):
    history = readings_db.get(device_id, [])
    cutoff = datetime.utcnow().timestamp() - (days * 86400)

    resting_readings = [
        r.bpm for r in history
        if r.resting and r.timestamp.timestamp() >= cutoff
    ]

    if len(resting_readings) < 5:
        return {"status": "insufficient_data"}

    return {
        "device_id": device_id,
        "average_resting_bpm": round(statistics.mean(resting_readings), 1),
        "sample_size": len(resting_readings),
        "days_covered": days,
    }

Arrhythmia detection, particularly for atrial fibrillation, adds another layer: instead of just averaging BPM, the algorithm looks at beat-to-beat interval variability. An irregular pattern across many consecutive beats is a stronger signal than any single fast or slow reading. This is roughly how consumer AFib detection features work, and it's also why regulatory bodies like the FDA have specifically cleared certain smartwatch features as medical software rather than treating them as generic fitness tracking.

Accuracy Limits Worth Knowing About

Wearable heart sensors are good, not infallible, and the gap matters for anyone building or relying on these systems. PPG accuracy degrades with darker skin tones in some devices, largely due to how green light interacts with melanin, a limitation that has drawn scrutiny from researchers and regulators alike. Tattoos, poor wrist fit, and cold hands can all throw off readings too, since they interfere with blood flow detection at the skin surface.

There's also a difference between what a fitness tracker reports and what's clinically actionable. A device flagging "possible AFib" is a screening signal, not a diagnosis. Responsible product design treats these alerts as a prompt to see a doctor and get a real ECG, not as a replacement for one. Anyone building a health-adjacent IoT product should be explicit about this distinction in both the UI and the documentation, since overstating accuracy creates real liability and, more importantly, can mislead someone about their actual health status.

Building for the Long Term

Heart health tracking is one of the clearer examples of IoT sensors delivering practical value rather than novelty. The sensors themselves are commodity hardware at this point; the differentiation comes from firmware that filters noise well, connectivity that doesn't drain the battery in a day, and backend logic that turns a stream of numbers into a trend a person can understand. Teams building in this space should treat the full pipeline — sensor, transport, and analysis — as one system to validate together, rather than optimizing each layer in isolation.

If you're prototyping a wearable heart rate feature, start with a BLE Heart Rate Service–compliant sensor module, build the ingestion API before you need it to scale, and test accuracy against a known reference device under real-world motion, not just at rest on a desk.

Fast and Smart: How Factories Use the Industrial Internet of Things

Fuad Husnan — Sat, 22 Aug 2026 12:05:34 +0000

The Industrial Internet of Things is no longer a pilot project confined to a single test line. It has become the operating layer that connects sensors, machines, and software across entire factory floors, letting manufacturers see problems before they become expensive ones. Global IIoT spending is projected to cross $600 billion in 2026, and manufacturing remains the single largest end-use segment driving that growth. What was once a futuristic add-on is now closer to standard equipment for any factory trying to stay competitive.

What the Industrial Internet of Things Actually Means

IIoT refers to networks of sensors, controllers, and connected machines that collect operational data and share it in real time, usually feeding into a central platform where engineers and managers can act on it. The concept overlaps with the broader consumer IoT world, but the stakes are different. A smart thermostat that misreports the temperature is an inconvenience. A pressure sensor on an industrial boiler that misreports its readings can shut down a production line or, worse, cause a safety incident.

This is why industrial deployments emphasize reliability, latency, and security far more than consumer devices do. A vibration sensor bolted to a motor housing needs to report consistently for years in a hot, dusty, electrically noisy environment, and the network carrying that data needs to stay up even when the plant's other systems don't.

From Reactive Maintenance to Predictive Maintenance

The most mature and widely adopted use case for IIoT in manufacturing is predictive maintenance. Traditional factories run equipment until it breaks, then scramble to fix it, or they follow rigid maintenance schedules that replace parts whether they need it or not. Both approaches waste money: one on unplanned downtime, the other on premature part replacement.

IIoT changes the model by monitoring equipment continuously. Vibration sensors, thermal cameras, and current sensors track how a machine behaves under normal conditions, and software flags deviations that typically precede failure. A bearing that starts vibrating slightly out of pattern, or a motor that draws more current than usual, becomes visible weeks before it would have caused a breakdown.

Here is a simplified example of how a factory might process incoming sensor readings and flag anomalies using a basic threshold model in Python:

import statistics

def check_vibration_anomaly(readings, baseline_mean, baseline_stdev, threshold=3):
    """
    Flags a sensor reading as anomalous if it deviates from the
    established baseline by more than `threshold` standard deviations.
    """
    current_mean = statistics.mean(readings)
    z_score = (current_mean - baseline_mean) / baseline_stdev

    if abs(z_score) > threshold:
        return {
            "status": "anomaly_detected",
            "z_score": round(z_score, 2),
            "current_mean": round(current_mean, 3)
        }
    return {"status": "normal", "z_score": round(z_score, 2)}

# Example: baseline vibration in mm/s established over normal operation
baseline_mean = 2.1
baseline_stdev = 0.35
recent_readings = [2.4, 2.6, 2.9, 3.1, 3.0]

result = check_vibration_anomaly(recent_readings, baseline_mean, baseline_stdev)
print(result)

Real deployments use more sophisticated models, often machine learning classifiers trained on years of historical failure data, but the underlying logic is the same: compare live readings against a known-good baseline and raise an alert when something drifts too far from it.

Real-Time Monitoring Across the Production Line

Beyond individual machines, IIoT gives plant managers a live view of the entire production line. Instead of relying on end-of-shift reports, supervisors can see throughput, defect rates, and machine status as they happen. This visibility matters because small inefficiencies compound quickly across a full shift or a full week.

A conveyor running slightly slower than spec, a station with a longer-than-normal cycle time, or a machine sitting idle waiting for parts, are all the kind of issues that are easy to miss in a walkthrough but obvious on a dashboard tracking data continuously. IoT analytics gives manufacturers the data they need to understand their performance and identify what is slowing them down, allowing that process to be automated further by combining IIoT systems with artificial intelligence.

Connectivity architecture matters here too. Many plants historically relied on wired plant networks that were expensive to extend and hard to reconfigure. The industry has been shifting away from plant-network-dependent architectures toward cellular connectivity, making it easier to deploy sensors on mobile equipment or in areas where running new cable isn't practical.

Quality Control and Reducing Waste

Manufacturing quality control has traditionally relied on sampling: pulling a handful of units off the line and inspecting them by hand. IIoT enables inline inspection instead, where every unit gets checked as it passes a sensor or camera station. Machine vision systems can catch surface defects, dimensional errors, or assembly mistakes that a sampling process would likely miss.

This shift matters most in industries with tight tolerances or expensive materials, where a defect caught early saves far more than one caught after several downstream processing steps have already been applied. It also generates a data trail that engineers can use to trace a quality issue back to its root cause, whether that's a specific machine, shift, or supplier batch.

The Adoption Gap Between Large and Small Manufacturers

IIoT adoption is uneven, and that unevenness says a lot about where the technology still faces friction. Around 72% of large manufacturers with 1,000 or more employees already have at least one IIoT pilot or production deployment, but only about a quarter to a third of them have scaled that pilot into an enterprise-wide rollout. Smaller manufacturers, those under 500 employees, sit at a lower 15 to 25% adoption rate.

That gap exists for practical reasons. Sensor hardware, network infrastructure, and the data engineering needed to make sense of the resulting streams all cost money and specialized staff that smaller operations often don't have on hand. The pilot-to-scale gap is arguably a bigger industry problem than the initial adoption decision: it's one thing to instrument a single line as a proof of concept, and another to standardize that setup across every line, shift, and facility a company operates.

Falling hardware costs are narrowing this gap gradually. Low-power sensors and edge AI chips have both gotten cheaper, which lowers the upfront cost of getting started, even if the integration work still takes real engineering time.

Edge Computing Is Changing Where the Intelligence Lives

Early IIoT systems sent nearly all their sensor data to the cloud for processing, which works fine until you're dealing with hundreds of sensors producing readings multiple times per second. Bandwidth becomes a real constraint, and round-trip latency to the cloud is too slow for use cases like halting a machine the instant an anomaly appears.

Edge computing addresses this by processing data locally, on a gateway device sitting on the factory floor, before deciding what needs to go to the cloud and what can be handled immediately. Over 87% of surveyed manufacturers agree that connected devices should become more intelligent and process data at the edge rather than sending everything to the cloud. A basic edge processing pattern looks something like this:

def process_sensor_batch(readings, edge_threshold=95.0):
    """
    Processes readings locally at the edge. Only readings that cross
    a critical threshold get forwarded immediately to the cloud;
    the rest are aggregated and sent in a batch later.
    """
    critical_alerts = []
    aggregate_batch = []

    for reading in readings:
        if reading["value"] >= edge_threshold:
            critical_alerts.append(reading)
        else:
            aggregate_batch.append(reading)

    if critical_alerts:
        send_to_cloud_immediately(critical_alerts)

    if aggregate_batch:
        queue_for_batch_upload(aggregate_batch)

    return {
        "immediate_alerts": len(critical_alerts),
        "batched_readings": len(aggregate_batch)
    }

This pattern, filtering at the edge and only escalating what genuinely needs attention, keeps bandwidth costs manageable and keeps response times fast enough to matter on a live production line.

Security Concerns That Come With Connectivity

Connecting industrial equipment to networks introduces risk that didn't exist when machines operated in isolation. Operational technology networks were never designed with internet connectivity in mind, and the consequences of a manufacturing cyberattack are physical rather than purely digital: a compromised control system can damage equipment or halt production, not just leak data.

This is one of the more honest trade-offs in the IIoT conversation. The same connectivity that enables predictive maintenance and real-time monitoring also expands the attack surface a plant has to defend. Manufacturers adopting IIoT at scale generally need to invest in network segmentation, keeping OT and IT networks separated, along with monitoring specifically built for industrial protocols, which differ from standard enterprise IT security tooling. Skipping this step to move faster on deployment tends to be a costly decision later.

Where This Is Heading

The trajectory is toward more intelligence living closer to the machines themselves, with cloud platforms handling the aggregation, historical analysis, and cross-plant comparisons that don't need to happen in real time. Artificial intelligence is increasingly layered on top of the raw sensor data, moving predictive maintenance models from simple threshold alerts toward genuinely learned patterns of failure. Several major industrial software vendors have recently rolled out AI-assisted tools aimed specifically at equipment diagnostics and maintenance planning, suggesting the next phase of IIoT is less about connecting more devices and more about making better use of the data already flowing in.

For manufacturers still early in the adoption curve, the practical starting point isn't a plant-wide overhaul. It's picking one line, one class of equipment, or one recurring failure mode, and instrumenting it well enough to prove the case internally before scaling further. The technology has matured to the point where the tools are no longer the bottleneck. The organizational work of integrating them into how a plant actually operates is where the real effort now lies.

Safe and Sound: Stopping Hacks in the Internet of Things

Fuad Husnan — Sat, 22 Aug 2026 11:56:10 +0000

Internet of Things security failures rarely start with a sophisticated exploit. They start with a camera that shipped with the password "admin" still active, a router nobody patched in three years, or a smart thermostat quietly leaking data over an unencrypted connection. By the end of 2025, an estimated 21.1 billion connected devices were online worldwide, and researchers were tracking roughly 820,000 malicious attempts against them every single day. That volume alone should reframe how builders, IT teams, and everyday device owners think about IoT security: not as an edge case, but as the default battlefield.

This piece looks at why IoT devices remain such an easy target, walks through the technical patterns behind the worst recent breaches, and gives concrete steps — including code — for closing the most common gaps.

Why IoT Devices Are Easier to Hack Than Computers

A laptop or phone gets regular software updates, runs endpoint protection, and usually sits behind a user who notices when something looks wrong. Most IoT devices have none of that. They're built to a price point, run stripped-down firmware, and are often installed once and never looked at again.

Routers and network edge devices illustrate the problem well. They account for the majority of IoT-related attacks and carry a disproportionate share of the most severe vulnerabilities, since compromising the device sitting between a network and the internet gives an attacker a foothold over everything behind it. Forescout's 2026 telemetry found that routers and switches now average around 32 vulnerabilities per device, and that these devices account for roughly a third of the most critical vulnerabilities found across enterprise networks.

Weak or unchanged default credentials remain one of the simplest and most common entry points. Manufacturers ship devices with predictable admin logins to make setup easy, and a large share of those credentials are never rotated. Attackers don't need to break anything sophisticated when the front door is already unlocked.

The Botnet Problem: When Your Toaster Joins an Attack

Individually, a compromised smart plug or IP camera isn't very useful to an attacker. Aggregated into the tens of thousands, it becomes a weapon. IoT botnets recruit exactly this kind of low-value, poorly monitored device, then use the combined bandwidth to launch distributed denial-of-service (DDoS) attacks against much bigger targets.

The scale here has grown sharply. Malicious IoT botnet activity increased roughly fivefold over the past year, with the population of compromised devices climbing from around 200,000 to close to a million, and these botnets now account for more than 40% of observed DDoS traffic. The Aisuru botnet, built substantially from hijacked IoT devices, was tied to a record-setting 29.9 Tbps DDoS attack in late 2025. The BadBox 2.0 botnet separately compromised more than 10 million consumer devices globally through a supply-chain infection baked into firmware before the products even reached buyers.

These numbers matter because they show the shift in the threat model. IoT security isn't only about protecting the device owner's data anymore — a poorly secured smart speaker in a home network can become a small contributor to an attack on infrastructure the owner has never heard of.

Encryption Gaps Are Still Widespread

A large share of IoT traffic still moves without encryption. Palo Alto Networks has reported that around 98% of IoT device traffic is unencrypted, meaning sensor readings, credentials, and command data often travel in plaintext across the network. Combined with tens of billions of active devices, that translates to a huge population of endpoints where a basic packet capture on the local network is enough to expose meaningful data.

This is a solvable problem at the protocol level, and it's where developers building IoT firmware or backend services have the most direct leverage. The following example shows a minimal but realistic pattern for authenticating an MQTT-connected device and encrypting its traffic with TLS, rather than trusting an open, unauthenticated broker connection — a configuration that's still common in production IoT deployments.

import ssl
import paho.mqtt.client as mqtt

BROKER_HOST = "broker.example.com"
BROKER_PORT = 8883  # TLS port, not the unencrypted 1883
DEVICE_ID = "sensor-department-04"
DEVICE_TOKEN = "REPLACE_WITH_SECRET_FROM_ENV"

def on_connect(client, userdata, flags, reason_code, properties=None):
    if reason_code == 0:
        print(f"{DEVICE_ID} connected securely")
        client.subscribe(f"devices/{DEVICE_ID}/commands")
    else:
        print(f"Connection failed with code {reason_code}")

client = mqtt.Client(client_id=DEVICE_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(DEVICE_ID, DEVICE_TOKEN)

# Enforce TLS instead of allowing a fallback to plaintext
client.tls_set(cert_reqs=ssl.CERT_REQUIRED, tls_version=ssl.PROTOCOL_TLS_CLIENT)
client.tls_insecure_set(False)

client.on_connect = on_connect
client.connect(BROKER_HOST, BROKER_PORT, keepalive=60)
client.loop_forever()

Three details in that snippet do most of the security work: the connection uses port 8883 with tls_set() enforced rather than the plaintext 1883 default, cert_reqs requires a valid certificate instead of accepting any endpoint, and the device authenticates with a per-device token rather than a shared password baked into every unit on the production line. None of this is exotic. It's the difference between a device that's defensible and one that isn't.

Firmware: The Update Problem Nobody Wants to Own

Unlike a phone or laptop, most IoT devices don't have a clear, user-facing update mechanism. Some can't be patched at all after deployment. Others technically support updates, but the process is manual enough that it rarely happens in practice. That gap is a major reason vulnerabilities discovered years ago are still being actively exploited today — CISA's Known Exploited Vulnerabilities catalog has recorded cases where nearly half of newly added entries were vulnerabilities disclosed well before the reporting period, meaning attackers are often exploiting flaws that were already public knowledge.

For teams building connected products, the fix isn't just "ship updates" — it's designing for updates from the start. A device that can verify and apply a signed firmware image over the air is fundamentally more defensible than one that requires physical access or manual flashing. Below is a simplified example of a firmware update handler that checks a cryptographic signature before applying an update, which prevents an attacker from pushing malicious firmware even if they can intercept the update channel.

import hashlib
import hmac

def verify_firmware(firmware_bytes: bytes, signature: str, shared_secret: bytes) -> bool:
    """Verify firmware integrity before flashing using HMAC-SHA256."""
    expected_signature = hmac.new(
        shared_secret,
        firmware_bytes,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected_signature, signature)

def apply_update(firmware_bytes: bytes, signature: str, shared_secret: bytes):
    if not verify_firmware(firmware_bytes, signature, shared_secret):
        raise ValueError("Firmware signature mismatch — update rejected")
    # Only reached if the signature check passes
    write_to_flash_partition(firmware_bytes)
    print("Firmware verified and applied")

The key line is hmac.compare_digest() rather than a plain == comparison — a constant-time comparison prevents timing attacks that could otherwise let an attacker infer the correct signature byte by byte. This kind of detail is easy to skip under deadline pressure, and it's exactly the kind of gap that separates a device that resists tampering from one that doesn't.

Regulation Is Catching Up, Slowly

Governments are starting to close the gap between how fast IoT devices ship and how weak their security baseline has been. The EU's Cyber Resilience Act introduces reporting obligations that take effect in September 2026, requiring manufacturers to report actively exploited vulnerabilities in connected products within a set window after discovery. In the US, the Cyber Trust Mark gives consumers a way to identify products that meet a baseline security standard before they buy.

These frameworks won't fix the installed base of billions of already-deployed devices, but they change the incentive structure for new products. A manufacturer that has to disclose exploited vulnerabilities on a deadline has a much stronger reason to build patchable firmware and secure defaults from day one, rather than treating security as a cost center to minimize.

What Actually Reduces Risk

For organizations managing IoT fleets, the highest-leverage moves are unglamorous. Replacing default credentials before a device goes into production, segmenting IoT traffic onto its own network rather than letting it share a subnet with sensitive systems, and enforcing encrypted connections at the protocol level closes the majority of the attack paths described above. Asset visibility matters just as much — a device that isn't in your inventory can't be patched, monitored, or removed when it's compromised, and unmanaged or forgotten devices are a recurring theme in the incidents researchers have documented over the past year.

For individual device owners, the same logic applies at a smaller scale. Change the default password immediately, keep firmware updated when the manufacturer supports it, and put smart home devices on a separate guest network rather than the same one used for laptops and phones handling sensitive accounts. A compromised smart bulb is a nuisance. A compromised smart bulb sharing a network with your banking session is a much bigger problem.

The Internet of Things isn't going to get less connected. Every year adds more sensors, more cameras, and more devices that quietly assume nobody is watching them closely. The organizations and developers who build in authentication, encryption, and patchability from the start are the ones whose devices stay out of the next botnet headline — and that's a far cheaper investment than cleaning up after one.

Connecting the City: How IoT Makes Urban Life Smart

Fuad Husnan — Sat, 22 Aug 2026 11:54:29 +0000

IoT is the reason a traffic light in Taiwan can now respond to real traffic instead of a fixed timer, and the results are hard to ignore: more than 100 AI-controlled signals working together have cut congestion by as much as 25% in early rollouts. That single example captures what the Internet of Things is actually doing to cities right now. It is not a futuristic concept anymore. It is sensors under the road, meters on the grid, and cameras on the lamp posts, all quietly feeding data into systems that make daily urban life run a little smoother.

The scale of this shift is no longer speculative. The global IoT in Smart Cities market was valued at roughly $214 billion in 2025 and is on track to pass $250 billion in 2026, with most forecasts putting it well above half a trillion dollars by the early 2030s. That growth is not driven by novelty. It is driven by cities that have run out of room to expand their physical infrastructure and are instead trying to squeeze more performance out of what they already have.

What "Smart City" Actually Means in Practice

The phrase "smart city" gets thrown around loosely, so it helps to define it in concrete terms. A smart city uses networks of connected sensors, actuators, and software platforms to collect data about physical infrastructure, then acts on that data automatically or semi-automatically. Traffic lights, water mains, streetlights, waste bins, and public transit vehicles all become nodes in a larger system rather than isolated pieces of infrastructure.

This matters because cities have historically managed these systems in silos. A water utility does not typically share real-time data with the transportation department, and a power grid operator rarely coordinates directly with waste management. IoT changes that by giving every one of these systems a common language: sensor data, timestamps, and location. Once that data exists, it can be pooled into a single dashboard or fed into predictive models that span departments.

The practical effect is that city governments start making decisions based on what is actually happening rather than on fixed schedules or historical averages. A garbage truck no longer follows the same route every day regardless of how full the bins are. A streetlight no longer burns at full brightness on an empty street at 3 a.m.

Traffic and Transportation: The Most Visible Win

Traffic congestion is usually the first problem cities try to solve with IoT, and for good reason. It is visible, it is measurable, and the return on investment tends to show up fast. Smart traffic systems combine road sensors, connected cameras, and adaptive signal controllers that adjust timing in real time based on actual vehicle flow rather than a preset cycle.

The architecture behind this is simpler than people expect. A typical deployment involves edge devices at each intersection that collect vehicle counts and speeds, then send that data upstream to a central optimization engine.

import time
import json
from dataclasses import dataclass

@dataclass
class IntersectionReading:
    intersection_id: str
    vehicle_count: int
    avg_speed_kmh: float
    timestamp: float

def compute_green_light_duration(reading: IntersectionReading,
                                  base_duration: int = 30,
                                  max_duration: int = 90) -> int:
    """Adjust green light duration based on real-time vehicle density."""
    congestion_factor = reading.vehicle_count / max(reading.avg_speed_kmh, 1)
    adjusted = base_duration + int(congestion_factor * 5)
    return min(adjusted, max_duration)

def process_intersection_stream(readings: list[IntersectionReading]) -> dict:
    signal_plan = {}
    for reading in readings:
        duration = compute_green_light_duration(reading)
        signal_plan[reading.intersection_id] = duration
    return signal_plan

# Example: readings pulled from intersection sensors every 60 seconds
sample_readings = [
    IntersectionReading("INT-014", vehicle_count=42, avg_speed_kmh=18.5, timestamp=time.time()),
    IntersectionReading("INT-015", vehicle_count=12, avg_speed_kmh=35.0, timestamp=time.time()),
]

plan = process_intersection_stream(sample_readings)
print(json.dumps(plan, indent=2))

That kind of logic, running across a network of intersections rather than one at a time, is what allows cities to treat traffic as a single connected system instead of hundreds of independent decisions. Congestion at one intersection can be anticipated before it spills into the next one, because the data from upstream sensors arrives seconds before the cars do.

Public transit benefits from the same approach. Real-time occupancy sensors on buses and trains let transit authorities adjust frequency during unexpected demand spikes, and passenger-facing apps can show accurate arrival times instead of static schedules. Once that data pipeline exists, it also becomes the foundation for longer-term planning, since transit agencies can see exactly which routes are over- or under-served at specific times of day.

Energy Grids and the Push Toward Efficiency

Energy management is where IoT has produced some of the clearest financial returns. Smart grids use connected meters and sensors to monitor electricity flow at a granularity that was simply not possible with traditional infrastructure. Utilities can detect outages within seconds instead of waiting for a customer to call, and they can reroute power around damaged sections of the grid automatically.

Smart lighting is a smaller-scale but widely deployed example, and it currently holds the largest revenue share within smart governance applications, at roughly 31.5% as of 2025. The concept is simple: streetlights equipped with motion and ambient light sensors dim automatically when no one is around and brighten when they detect pedestrians or vehicles. Multiply that behavior across tens of thousands of streetlights in a mid-sized city, and the energy savings compound quickly.

Virtual power plants are a more advanced application worth knowing about. These systems combine distributed energy resources, such as home solar panels, battery storage units, and electric vehicle chargers, into a single coordinated network that can deliver backup capacity during peak demand. Some pilot programs are already able to supply up to 100 MW of backup grid capacity this way, which is a meaningful contribution during heat waves or unexpected demand surges, without building a single new power plant.

Water, Waste, and the Less Glamorous Infrastructure

Not every IoT application in cities gets attention, but some of the least visible ones deliver the most consistent value. Water utilities lose a significant percentage of treated water to leaks in aging pipe networks every year, and much of that loss goes undetected for months. Acoustic sensors placed along water mains can detect the specific sound signature of a leak long before it becomes a visible break in the street, cutting repair costs and water loss simultaneously.

Waste management has undergone a similar transformation. Traditional garbage collection follows fixed routes on fixed days regardless of how full any individual bin actually is. IoT-enabled waste bins report their fill level to a central system, which then generates collection routes based on actual need. Early deployments of this approach have reduced the number of collection truck runs by as much as 90% in specific pilot programs, which translates directly into lower fuel costs, less vehicle wear, and reduced emissions from the collection fleet.

The waste management segment is also expected to see the fastest growth rate of any smart utility category between 2026 and 2033, as more municipal governments move past the pilot phase into full deployment.

The Data Backbone Behind All of It

None of these applications work in isolation, and this is where the engineering complexity actually lives. A functioning smart city needs a data pipeline that can ingest readings from thousands of heterogeneous devices, normalize that data into a consistent format, and route it to the right consuming system, whether that is a traffic controller, a utility dashboard, or a public-facing app.

Message queuing systems like Kafka or MQTT brokers typically sit at the center of this architecture, since they can handle the high-frequency, high-volume nature of sensor data without forcing every downstream service to talk directly to every device.

from confluent_kafka import Consumer, Producer
import json

def create_sensor_consumer(topic: str, group_id: str) -> Consumer:
    config = {
        'bootstrap.servers': 'localhost:9092',
        'group.id': group_id,
        'auto.offset.reset': 'earliest'
    }
    consumer = Consumer(config)
    consumer.subscribe([topic])
    return consumer

def route_sensor_reading(reading: dict, producer: Producer) -> None:
    """Route incoming sensor data to the appropriate downstream topic."""
    sensor_type = reading.get('sensor_type')

    topic_map = {
        'traffic': 'city.traffic.processed',
        'water': 'city.water.leak-detection',
        'waste': 'city.waste.fill-level',
        'energy': 'city.energy.grid-status'
    }

    destination_topic = topic_map.get(sensor_type, 'city.unclassified')
    producer.produce(destination_topic, value=json.dumps(reading).encode('utf-8'))
    producer.flush()

This kind of routing layer is what allows a city to add new sensor types over time without redesigning the entire system. A newly deployed air quality sensor network, for example, can plug into the same message bus that traffic and water systems already use, rather than requiring its own dedicated infrastructure from scratch.

Security is a real constraint here, not a footnote. A 2024 study tracked more than 9 billion security events across roughly 50 million IoT devices, which is a useful reminder that every sensor added to a city network is also a potential entry point for attackers. Municipal IoT deployments generally need device-level authentication, encrypted transport, and network segmentation that keeps a compromised streetlight controller from having any path to, say, the water treatment system.

Where This Is Actually Headed

The most interesting shift happening in 2026 is not more sensors, it is more autonomy. Early smart city deployments were largely about sensing and reporting: a dashboard would show a city planner that traffic was building up, and a human would decide what to do about it. The systems being deployed now increasingly act on that data directly, adjusting signal timing, rerouting power, or dispatching maintenance crews without waiting for manual approval.

That shift raises legitimate questions that cities are still working through. Automated systems need clear override mechanisms for edge cases a sensor network cannot anticipate, and residents deserve transparency about what data is being collected and how long it is retained. Cities that get this balance right tend to treat IoT as an operational layer that supports human decision-makers rather than one that replaces them entirely.

For engineers and product teams building in this space, the opportunity is less about inventing new sensor hardware and more about building the integration layer that makes disparate city systems talk to each other reliably. The cities seeing the strongest results, whether that's Taiwan's traffic network or the municipalities piloting AI-assisted emergency response, are the ones that treated data architecture as seriously as the hardware itself.

If you're evaluating an IoT platform for municipal infrastructure, start by asking how it handles device failure and network partitioning, not just what it does when everything works. A sensor network that goes silent during a storm is far more dangerous than no sensor network at all if the city has come to depend on it. Building that resilience in from the start is what separates a smart city pilot from a smart city that actually holds up under real conditions.

Lightweight Encryption Protocols for Resource-Constrained IoT Devices

Fuad Husnan — Sat, 15 Aug 2026 07:55:28 +0000

Lightweight encryption protocols exist because standard cryptography assumes resources that most IoT devices don't have. A temperature sensor running on a coin cell battery cannot afford the RAM, CPU cycles, or power draw that AES-256 or RSA-2048 demand on a server. This gap between what conventional encryption needs and what embedded hardware can supply has produced an entire category of ciphers built specifically for constrained environments.

Why Standard Cryptography Fails on Small Devices

Most encryption algorithms were designed for desktops, servers, and phones — devices with abundant memory, fast processors, and a stable power supply. IoT endpoints rarely have any of that. A typical microcontroller used in a smart lock or industrial sensor might carry 8-32 KB of RAM and run at speeds measured in single-digit megahertz, not gigahertz.

// Typical constrained IoT device profile
#define RAM_AVAILABLE_KB      16
#define FLASH_AVAILABLE_KB    128
#define CPU_CLOCK_MHZ         8
#define BATTERY_CAPACITY_MAH  220
#define EXPECTED_LIFESPAN_YRS 5

Under these constraints, running AES-256 in software can consume RAM the device simply doesn't have left over after handling sensor input, networking stacks, and application logic. RSA key exchange is worse — the modular exponentiation involved can take seconds on an 8-bit microcontroller, draining battery reserves that are meant to last years, not days.

Engineers working on constrained hardware face a three-way trade-off: security strength, computational cost, and energy consumption. Lightweight cryptography doesn't eliminate this trade-off. It shifts the curve, offering security margins appropriate for the threat model while fitting inside a fraction of the memory and power footprint.

What Makes a Cipher "Lightweight"

The term lightweight cryptography refers to a specific design philosophy rather than a single algorithm. NIST formalized this category through its Lightweight Cryptography Standardization project, which ran from 2018 to 2023 and evaluated dozens of candidate algorithms against criteria including silicon area, RAM footprint, energy per bit, and resistance to side-channel attacks.

Three properties distinguish lightweight ciphers from their conventional counterparts:

Smaller block and key sizes reduce the memory needed to hold intermediate cryptographic state. Simplified round functions cut the number of CPU cycles required per encryption operation. Reduced code size means the compiled binary fits within the limited flash storage typical of microcontrollers, sometimes under 2 KB.

// Comparing memory footprint: AES-128 vs ASCON (illustrative)
struct cipher_footprint {
    const char *name;
    int ram_bytes;
    int rom_bytes;
    int cycles_per_byte;
};

struct cipher_footprint aes128  = {"AES-128", 512, 4096, 180};
struct cipher_footprint ascon128 = {"ASCON-128", 128, 2048, 90};

These are representative figures rather than benchmarks from a specific chip, but they illustrate the general pattern: lightweight ciphers aim to do more with meaningfully less.

ASCON: The Current NIST Standard

In February 2023, NIST selected the ASCON family as the winner of its Lightweight Cryptography competition, and in 2025 it was formally published as NIST SP 800-232. ASCON is an authenticated encryption with associated data (AEAD) construction, meaning it provides both confidentiality and integrity checking in a single pass rather than requiring separate encryption and MAC operations.

#include <ascon.h>

int encrypt_sensor_reading(uint8_t *plaintext, size_t pt_len,
                             uint8_t *key, uint8_t *nonce,
                             uint8_t *ciphertext, uint8_t *tag) {
    ascon_aead_ctx_t ctx;
    ascon_aead128_init(&ctx, key, nonce);
    ascon_aead128_encrypt(&ctx, ciphertext, plaintext, pt_len);
    ascon_aead128_finalize(&ctx, tag);
    return 0;
}

ASCON's sponge-based construction is what allows it to run in such a small footprint. Unlike AES, which relies on lookup tables that consume both memory and are a known vector for cache-timing side-channel attacks, ASCON's permutation-based design avoids table lookups entirely, making it inherently more resistant to certain timing attacks on constrained hardware.

PRESENT and SPECK: Earlier Lightweight Approaches

Before ASCON became the standardized answer, several other lightweight ciphers saw adoption in specific contexts. PRESENT, developed in 2007, is an ultra-lightweight block cipher designed for RFID tags and similarly constrained applications, using a 64-bit block size and either 80-bit or 128-bit keys.

SPECK, published by the NSA in 2013, takes a different approach, favoring simple addition, rotation, and XOR (ARX) operations that map efficiently onto both software and hardware implementations.

// SPECK round function (simplified, 32-bit words)
void speck_round(uint32_t *x, uint32_t *y, uint32_t k) {
    *x = (*x >> 8) | (*x << 24);  // rotate right 8
    *x += *y;
    *x ^= k;
    *y = (*y << 3) | (*y >> 29);  // rotate left 3
    *y ^= *x;
}

SPECK's reliance on simple arithmetic rather than substitution tables made it attractive for software-only implementations on devices without dedicated cryptographic hardware. It drew criticism, however, over its NSA origin and the absence of public design rationale for some parameter choices, which slowed formal standardization despite its practical performance advantages.

Elliptic Curve Cryptography for Key Exchange

Symmetric ciphers like ASCON and SPECK handle bulk data encryption efficiently, but IoT devices still need a way to establish shared keys in the first place. This is where the size advantage of elliptic curve cryptography (ECC) over RSA becomes significant: a 256-bit ECC key offers security roughly comparable to a 3072-bit RSA key, at a fraction of the computational cost.

// ECDH key exchange using Curve25519 (via a lightweight library)
#include <monocypher.h>

void generate_shared_secret(uint8_t *my_private_key,
                              uint8_t *their_public_key,
                              uint8_t *shared_secret) {
    crypto_x25519(shared_secret, my_private_key, their_public_key);
}

Curve25519 has become a common choice for constrained devices because its implementation avoids many of the timing-attack pitfalls that plague naive elliptic curve implementations, and reference code exists that compiles to just a few kilobytes of flash.

Protocol-Level Considerations Beyond the Cipher

Choosing an efficient cipher solves only part of the problem. The communication protocol wrapping that cipher matters just as much for real-world deployments. DTLS (Datagram Transport Layer Security), the UDP-based counterpart to TLS, is commonly paired with CoAP (Constrained Application Protocol) in IoT deployments, but full DTLS handshakes can still be too heavy for the most constrained devices due to certificate exchange overhead.

This has driven interest in pre-shared key (PSK) modes, which skip certificate-based authentication entirely in favor of keys provisioned during manufacturing.

// DTLS PSK configuration example (mbedTLS)
mbedtls_ssl_conf_psk(&conf,
                      psk, psk_len,
                      (const unsigned char *)psk_identity,
                      strlen(psk_identity));

PSK mode trades the flexibility of certificate-based trust for a dramatically lighter handshake, which matters when a device wakes from deep sleep, needs to transmit a reading, and must return to sleep within a strict energy budget.

Matching Protocols to Threat Models

Not every IoT deployment needs the same security posture. A soil moisture sensor reporting non-sensitive agricultural data has a different risk profile than a medical device transmitting patient vitals or an industrial controller managing physical machinery. Lightweight cryptography is not a shortcut around security; it's a recalibration of the trade-off between protection and resource cost for a given threat model.

Devices handling sensitive data still warrant the strongest lightweight cipher available, such as ASCON-128a for higher throughput needs, combined with proper key rotation and secure boot to prevent firmware tampering. Lower-stakes telemetry devices may reasonably use a smaller security margin if it meaningfully extends battery life across a large deployed fleet, provided the failure mode of a compromise remains low-consequence.

The honest limitation worth stating plainly: lightweight ciphers generally offer smaller security margins than their full-strength counterparts, and some, like SPECK, faced pushback during standardization over trust and transparency concerns. Engineers should treat cipher selection as one part of a layered security architecture, not a single point of defense, and should stay current with NIST guidance as SP 800-232 implementations mature across hardware platforms.

Bringing It Together

The shift toward lightweight cryptography reflects a broader recognition that security has to fit the hardware it protects. ASCON's selection as the NIST standard gives engineers a well-vetted default for new designs, while ECC-based key exchange and PSK-mode DTLS address the handshake overhead that often gets overlooked when teams focus only on the encryption algorithm itself. For teams building constrained IoT products today, the practical starting point is ASCON for authenticated encryption, Curve25519 for key agreement, and a protocol stack — CoAP over DTLS with PSK where certificate overhead isn't justified — sized to the device's actual power and memory budget rather than borrowed wholesale from enterprise networking.

Before finalizing a cryptographic approach for a new IoT product, benchmark candidate ciphers directly on your target hardware rather than relying on published figures alone, since real-world performance varies significantly across microcontroller architectures and compiler optimizations.