Company Overview
Smallstep [1], is a top 10 finalist at the 2025 RSAC Innovation Sandbox competition. It is a security company focusing on Zero Trust, identity and certificate management. Founded in 2016 and headquartered in California, Smallstep is currently in the state of Series A financing. In 2022, it received US$26 million in financing. Its investors include STEPSTONE, MHALF, boldstart, etc. Figure 1 shows the lead investors of Smallstep. Figure 2 shows the core members of Smallstep. Mike Malone, co-founder and CEO of the company, was previously a software engineer at Six Apart. He is an advocate of open source and open quasi-technology and a contributor to Django [2] (Note: Django is an open source Python web framework that encourages rapid development). Mike is also actively involved in the development of OAuth and Activity Streams standards, and he is a member of the Open Web Foundation.
Figure 1 Lead investors of Smallstep
Figure 2 Core members of Smallstep
Smallstep focuses on device identity, ensuring that only trusted company-owned devices can access the organization’s most sensitive resources. The Smallstep Device Identity PlatformTM leverages hardware-backed certificates through ACME Device Authentication (ACME DA), a new standard that the company developed in collaboration with Apple and Google. This hardware-backed approach provides the strongest guarantee for the true identity of the device, which can prevent credential leakage, phishing and counterfeiting attacks. The Smallstep Device Identity PlatformTM protects a variety of resources, including Wi-Fi and VPN networks, public SaaS applications, internal web applications, cloud services, cloud APIs, and Git repositories. Smallstep provides a comprehensive solution for device security through hardware-backed authentication and key binding, which supports multiple operating systems including Windows and Linux.
Background introduction
When it comes to identity authentication, most of us would think of Zero Trust. As a security concept, Zero Trust assumes that no entity (user, system or device) is inherently trustworthy, so every access request must be authenticated. With remote work, cloud computing and digital transformation expanding the potential attack surface, Zero Trust has become a top priority in security architecture. When most organizations practice the concept of Zero Trust, they focus on human identification-implementing single sign-on (SSO), multi-factor authentication (MFA) and user access policies. User authentication is crucial, but it’s only half the battle. Each endpoint(laptop, server, container, IoT device) can also be a potential target for threats in the environment. Even the more advanced user authentication (SSO, MFA) cannot detect which endpointdevice is accessing. If employees or attackers who steal user credentials can log in from unauthenticated laptops and virtual machines, Zero Trust will lose a lot of value.
This is where device identity comes in: it ensures that only legitimate, approved company-owned devices can access the most sensitive resources. While device authentication is designed to work with other endpoint security measures such as device posture checking, its real advantage lies in preventing any unknown or unauthorized device from gaining access, even if they have valid user credentials.
Traditional authentication methods such as Mobile Device Management (MDM) are often paired with the Simple Certificate Enrolment Protocol (SCEP), but they have a serious flaw, that is, it is difficult to ensure that the right machine has been added, and it is difficult to verify whether it belongs to the organization as well as whether it is the device you want to access. This makes it possible for abuse. For example, if a phishing scammer leaks a user’s access credentials, they could use these credentials to add unauthorized devices to the user’s list of managed devices. The MDM solution would then automatically provide the device with a SCEP profile that includes challenges. This allows the device to successfully apply for a client certificate from an internal CA, which can in turn be used to verify other internal systems.
So, what are the requirements for Zero Trust Endpoint Trust Authentication?
Continuous authentication: Trust must be built and re-verified at every step. If a device is attacked, its access rights should immediately reflect this change.
Hardware-based proof: By binding device credentials to a hardware root of trust (such as a TPM chip or Apple’s Secure Enclave), the likelihood of credential cloning or certificate spoofing can be greatly reduced.
Short-term certificates: Frequent renewal of certificates ensures that even if an attacker manages to obtain the certificate, it will become ineffective in a very short time. ,
Consistency check: Consistent device checks must be performed across all access channels (from VPN and Wi-Fi to SSH and web applications) to avoid blind spots in the security posture.
Smallstep Device Identity PlatformTM
Smallstep uses ACME device authentication to issue encryption certificates bound to the hardware root of trust. This process ensures that each laptop, server or virtual machine is a unique and verifiable device. Figure 3 is Smallstep’s Device Identity Platform.
Figure 3: Smallstep’s Device Identity Platform
Smallstep’s Device Identity Platform has the following features:
Hardware-based device authentication: When a device applies for a certificate, Smallstep ensures that the certificate is bound to the hardware-level identity.
Automated device credential lifecycle management: After successfully verifying the identity of the device, each device will receive a short-term certificate. Certificates are rotated regularly, and if a device is lost or compromised, the certificate will be revoked immediately.
Seamless integration: Smallstep integrates with SSH, Wi-Fi, RADIUS, VPN, Git and other environments, and the device automatically presents a valid certificate when requesting access.
Consistent policies and credentials: When resources are accessed, consistent device credentials must be used. If the device is no longer trusted, it will be locked out of all sensitive systems at the same time.
Centralized audit log: Security teams can immediately see which devices are accessing what content and can easily identify unusual usage.
Easy to expand: With the emergence of new device types (IoT sensors, containerized workloads), they can be easily integrated into the same platform.
Use cases for Smallstep
– Secure development: R&D engineers usually have local development machines. How to ensure that code submissions are only from approved company-owned devices? Each developer laptop will receive a hardware binding certificate. The Git server will reject any submission without a valid device certificate.
-Remote work: Teams working from multiple locations use VPNs, Wi-Fi, and web applications, and the use of personal devices adds complexity. How to ensure that connections are limited to approved company-owned devices? Only devices with short-lived authentication certificates should be granted access, ensuring that remote sessions originate from genuine company-owned endpoints.
– Cross-platform certificate management: Users have a mix of Windows, macOS, and Linux systems, as well as cloud instances. How to obtain certificates and configurations for devices that are in MDM? Smallstep’s platform can issue certificates for each operating system and containerized application, ensuring seamless authentication for every machine. Many MDM tools lack support for Linux; for example, Intune only supports Windows, and Jamf only supports Mac. Figure 4 illustrates Smallstep’s cross-platform certificate management.
Figure 4: Smallstep’s cross-platform certificate management
Technology behind Smallstep: TPM
How to safely and reliably identify an endpoint device? One way to solve this problem is to add a hardware module dedicated to secure storage and computing. Hardware modules takes many forms, such as integrated into the CPU or as dedicated hardware devices. The hardware module can provide functions such as key security storage, pseudo-random number generator and secure calculation. With these features, it is possible to anchor trust in hardware modules without having to trust the entire device hardware. Because hardware modules usually have fewer functions, physical components and firmware than complete devices, it is easier to verify their security attributes, thereby reducing the overall attack surface.
A Trusted Platform Module (TPM) is a piece of hardware that provides an authentication method. TPM is a secure coprocessor that uses standard interfaces. The Trusted Computing Group (TCG) has developed an interface specification, whose current version is 2.0. The standard interface stipulates that each TPM has an endorsement key (EK) which is a private key created or injected by the TPM manufacturer at the time of manufacturing. Private keys cannot be extracted from TPM, but TPM manufacturers will authenticate their public parts.
A special attribute of EK is that it cannot be used to sign data and therefore cannot be used directly to prove the identity of a device. EK can only decrypt data encrypted with its public key. The key usage restrictions built into the TPM module enable the unique characteristics of EK. This is a deliberate design choice intended to prevent the TPM from being used for tracking purposes that could identify devices. As a result, proving its identity requires a slightly more complex process known as device authentication. This process involves three main components: the (platform) certifier, the (platform) verifier, and the TPM. Here’s how it works:
- The certifier obtains the EK certificate from the TPM.
- The certifier instructs the TPM to generate an Attestation Key (AK) and its corresponding certificate, which includes application-specific identifiers, such as a unique device ID.
- The certifier combines the AK and EK certificates and sends them to the verifier.
- The verifier checks whether the EK certificate was issued by a trusted TPM manufacturer and cross-references the identity information with data from the manufacturing process.
- If the verification is successful, the verifier encrypts a random challenge using EK’s public key.
- The certifier sends a command to the TPM to decrypt and sends the decrypted result to the verifier.
- The verifier checks whether the received plaintext matches the one it previously generated. If it does, the verifier generates a certificate for the AK and sends it to the certifier.
Figure 5: TPM certification process
Summary
Digital certificates, as credentials for machine-to-machine authentication, play an indispensable role among companies. The number of machine identities has exceeded that of humans and will continue to multiply [3]. Certificate life cycle management (CLM) is a set of processes that support the discovery, inventory, issuance (via the appropriate Certificate Authorities CA), storage, deployment, revocation and update of digital certificates. Smallstep uses trusted hardware TPM to verify the identity of endpoint devices, helping Zero Trust extend from user authentication to endpoint device authentication. Smallstep was also selected for the Gartner report “Effectively Manage Your Organization’s Certificates”[4] for this innovative feature. In a previous issue of NSFOCUS Research Newsletter, we introduced TPM-related technologies. Traditional TPM-based applications include trusted boot and integrity measurement. Interested readers can refer to [5-7]. Whether Smallstep can stand out from the crowd of AI-focused startups remains to be seen.
References
1.https://smallstep.com/
2. https://www.djangoproject.com/
3. https://www.cyberark.com/resources/ebooks/cyberark-2023-identity-security-threat-landscape-report
4. https://www.gartner.com/document/5216363
5. https://mp.weixin.qq.com/s/10CDEzaHEp-gUxbhq5CYvA
6. https://mp.weixin.qq.com/s/8BXuJJOh1BY3BHq75H1zgQ
7. https://mp.weixin.qq.com/s/showAKatT3TsN11aWRD9GQ
