Standards for a Machine‑First Future: SPICE, WIMSE, and SCITT

If you are reading this on an internet-connected device, you have the Internet Engineering Task Force to thank. The IETF is responsible for developing and maintaining the open standards that power the internet, including foundational protocols like HTTP, TCP/IP, DNS, and TLS, ensuring that networks, browsers, servers, and devices from around the world can communicate seamlessly and securely. Without the IETF’s work in publishing and evolving these specifications through consensus-driven RFCs, the open, interoperable, and scalable internet would not exist.

Now, the IETF has expanded its mission to standardize how machines can securely connect and communicate. Today, production environments hum with API requests, CI tasks, and containerized workloads that trade secrets millions of times a day. These non‑human identities have outpaced the tools designed for people, and the gap keeps showing up in news about leaked credentials and poisoned build pipelines. 

Why a New Generation of Standards Became Inevitable

Standards are critical because they ensure interoperability, security, scalability, and maintainability across applications and tools. By adhering to common protocols, data formats, and security practices, systems can reliably communicate and integrate, reducing complexity and vendor lock-in. Standards also streamline development and testing, improve compliance with regulatory requirements, and make detecting and mitigating vulnerabilities easier by enforcing consistent behavior and expectations across diverse environments.

Existing standards like OAuth, OpenID Connect, and SPIFFE each solve important pieces of the identity and access management puzzle. Yet, none of them answer the full set of supply‑chain questions regulators and engineers now must ask. Security teams need to prove where every artifact came from, rotate credentials automatically across clouds, and share only the minimum data partners require.

The U.S. Executive Order 14028 and the EU Cyber Resilience Act both demand that level of evidence, pushing the community toward fresh blueprints rather than incremental patches. That urgency is what led to the charters for SCITT in October 2022, WIMSE in March 2024, and SPICE in June 2024.

Let's take a closer look at these three new working groups' missions. 

WIMSE: A Common Tongue for Workload Identities

WIMSE stands for Workload Identity in Multi-System Environments, and it’s all about solving the problem of how to make different services running in various systems, like across multiple clouds, data centers, or vendors, prove who they are to each other in a standardized, secure way. Right now, each environment may use a different method, most likely a long-lived credential, and getting them to work together often requires messy, custom code. WIMSE wants to fix that by creating a common language for workload identities.

To do this, the working group is building a reference architecture and a set of token translation rules. These will allow existing identity formats, like JSON Web Tokens (JWTs), SPIFFE IDs, mTLS certificates, and Remote Attestation Tokens (RATS), to interoperate cleanly, so systems can trust each other without needing hand-written “glue” logic. The goal is to translate identity formats in a clean, standardized way so everything can talk securely and consistently.

What makes WIMSE forward-thinking is its focus on continuous and fine-grained identity checks, rather than the traditional model where identities are verified just once, like at login or initial use of an API key. This is especially important for automated workloads that spin up and down frequently or move between environments. By supporting real-time, low-trust-by-default validation, WIMSE is aiming to make machine-to-machine communication more secure and scalable, even in complex multi-cloud setups.

SPICE: Privacy‑Respecting Digital Credentials

Secure Patterns for Internet Credentials (SPICE) is a project focused on giving users more control over their digital identity and credentials. Instead of sending an entire document or data set to prove something, like your age or employment, SPICE lets you reveal only the specific pieces of information needed, this is called selective disclosure. It’s kind of like showing a bouncer that you're over 21 without also showing your home address or full ID.

SPICE does this by using and customizing modern cryptographic formats like JOSE (JSON Object Signing and Encryption), COSE (CBOR Object Signing and Encryption), and the new JSON Web Proof (JWP) format. These formats are designed to let users create verifiable claims that can be checked by someone else (a verifier) without giving away more than necessary. This adds privacy and security, especially important when handling sensitive data.

This approach is already being explored in several real-world scenarios. For example, it can be used to attach digital authenticity tags to products in a supply chain, so a buyer can verify they’re genuine. It’s also useful for IoT devices with limited processing power, where lightweight cryptographic proofs are needed. Another use case is offline credential sharing, like securely transferring access rights in remote facilities without internet access. In short, SPICE aims to make credentials both secure and privacy-preserving, even in tricky environments.

SCITT: Receipts for Every Artifact

The Supply Chain Integrity, Transparency, and Trust (SCITT) working group is designing a security system that helps track and verify the origin and journey of both software and physical goods. Think of it like creating a digital passport for every package, software, or hardware, showing where it came from, who worked on it, and whether it can be trusted. This "notarization layer" ensures that you can prove the integrity of a file or object just by checking its digital record.

To do this, SCITT uses three core components: 

1. A transparency log that records events like builds and signatures in a tamper-evident way.
2. An evidence model that defines what kind of proof is required to say a package is trustworthy.
3. A trust registry that lists who is allowed to sign or certify things. 

This setup means anyone, developers, security teams, or even users, can cryptographically verify how a piece of software was created and whether it's been manipulated.

When it's fully deployed, SCITT will work like Certificate Transparency did for TLS/SSL certificates: instead of just trusting that something is safe because it's signed, you'll be able to verify the entire lifecycle of the item. From code being written to build, test, sign-off, and deployment, it’ll all be traceable, signed, and provable with cryptography. That’s a massive step toward stopping supply chain attacks and ensuring trust in large-scale systems.

How All the Pieces Fit

These three efforts, SCITT, SPICE, and WIMSE, form a complete, end-to-end trust fabric for modern software and system environments. It starts with SCITT, which provides a tamper-evident ledger that records every meaningful event in a software or physical product’s lifecycle, from code commits, builds, test results, and security scans to deployment approvals and shipping. This ledger creates a shared source of truth that anyone can audit, proving that artifacts in a system haven’t been maliciously modified or improperly promoted. The log is cryptographically verifiable and open, much like what Certificate Transparency did for digital certificates.

Then SPICE enters the picture to selectively transform that raw audit data into credentials, small, signed claims that prove something about an artifact, device, or process without leaking sensitive or unnecessary information. For example, SPICE could turn a long build pipeline record into a lightweight proof that just says, “This firmware was built from vetted source code and passed all checks,” revealing only what’s needed to verify compliance. 

Finally, WIMSE ensures that the microservices or workloads exchanging these credentials can actually trust each other, even if they’re running in totally different environments, AWS, GCP, Kubernetes clusters, or edge nodes. WIMSE standardizes identity verification for workloads using things like JWTs, SPIFFE, or mTLS, making sure that only authorized components can make claims, access logs, or consume credentials. Together, the trio enables a secure, verifiable, and privacy-preserving supply chain from code to runtime execution.

GitGuardian is Here to Help You Get There

Before any organization can successfully adopt identity standards like SPIFFE or WIMSE, it must first gain full visibility into how machine identities, workloads, services, and automation scripts are currently authenticated. GitGuardian’s NHI Security platform offers exactly that: a comprehensive platform that discovers, inventories, and monitors machine identities across your entire SDLC.

GitGuardian can map credentials, like API keys, tokens, and hardcoded secrets, to the specific services and environments using them. This insight is critical because it not only surfaces hidden dependencies but also reveals trust relationships and lifecycle risks, allowing you to understand what would break and what could be exploited during a shift to short-lived, certificate-based authentication.

GitGuardian NHI can help teams identify where overprivileged, long-lived secrets can be replaced with dynamic identities. This makes it a natural stepping stone to adopting SPIFFE/SPIRE architectures, which issue ephemeral certificates, or integrating with WIMSE, which relies on portable, verifiable workload identities. In parallel, the telemetry provided by NHI feeds directly into SPICE-style selective disclosure. It can be anchored in SCITT’s auditable ledger, helping your org build a fully traceable and privacy-respecting trust chain.

GitGuardian doesn’t just help you manage secrets; it helps you model, modernize, and migrate your non-human identity architecture into a future-ready security posture.

Moving Forward

Start by inventorying every non‑human identity in your environment and scanning your repositories for long‑lived keys. Join the SPICE, WIMSE, and SCITT mailing lists to influence the drafts before they reach last call. Finally, run a GitGuardian audit to clear out legacy secrets and position your pipelines for a standards‑ready future. Once those basics are covered, the transition from today’s ad‑hoc practices to tomorrow’s machine‑first trust fabric becomes far less daunting.