One protected starting point
Windows Server 2019 or later, Microsoft AD CS and Microsoft SQL Server or PostgreSQL form the compact starting point.
SMALL FOOTPRINT · HIGH SECURITY EXPECTATION
Start with one server and an integrated CA—not with unnecessary complexity.
Core, database, Microsoft AD CS and agent can run together on one protected Windows Server. An Active Directory domain is not mandatory. Connect AD and Microsoft Entra ID as needed; add further CAs and outposts later.
VALUE IN 30 SECONDS
A small deployment can still follow a complete trust process.
The full identity lifecycle
Inventory, Register, Assign, user-led enrollment, renewal with a new key and loss handling are part of the small starting setup.
A path beyond the first server
Additional CAs, domains, forests, sites and Outposts can be connected as the organization grows.
START COMPACT · KEEP THE CONTROL MODEL
What does a sensible first x.ID deployment need?
The first architecture should be small enough to operate and complete enough to remain trustworthy. It must also preserve a clear extension path rather than becoming a disposable pilot.
-
01
Define the first identity use case
Start with a limited user group and a concrete use case, such as PIV certificate authentication or a controlled administrative identity.
-
02
Choose Windows Server and database
The Core runs on Windows Server from 2019 through supported current server versions. Microsoft SQL Server is supported across editions; PostgreSQL is also available.
-
03
Use the integrated CA for the first PKI path
The integrated CA currently uses Microsoft Active Directory Certificate Services (AD CS) on the same server. An AD domain is not mandatory for the confirmed small setup.
-
04
Connect Active Directory or Entra ID when needed
Include on-premises users and computers through the LDAP Connector and connect cloud identities directly to Microsoft Entra ID through the native Azure Connector.
-
05
Bind hardware, identity and policy
Register supported security keys, assign accountable identities and enforce the required approval and attestation rules before issue.
-
06
Test operations and rebuilding
Test normal issuance, renewal, loss response and revocation. Scripted, documented installation also makes rebuilding reproducible, including HSM integration and certificate/key setup.
-
07
Extend instead of rebuilding
Add further domains, forests, CAs, locations and Outposts while retaining the same identities, policies and lifecycle evidence.
THE ARCHITECTURE AT A GLANCE
One server for Core, database, AD CS and agent. Directories and HSM as needed.
TECHNICAL DEPTH
Compact does not mean incomplete.
The deployment reduces infrastructure, not the required trust decisions. These technical boundaries remain important from the first use case.
- Microsoft AD CS on the initial server
- The integrated CA currently uses Microsoft Active Directory Certificate Services (AD CS) on the same server. An AD domain is not mandatory for the confirmed small setup.
- Agent on client or jump host
- The x.ID Agent runs on the client or on a jump host with supported smart card redirection. No local installation does not mean no agent. The YubiKey stays at the user’s computer; the agent communicates with the Core over mTLS.
- Tested client platforms
- The confirmed test scope covers Windows 10, Windows 11 and the current macOS build. The actual hardware, client and remote-access combination is checked before rollout. Certificate use on a target system does not imply native agent support on every operating system.
- OIDC / SSO
- In the recommended standard workflow, the OIDC-authenticated end user performs enrollment. SSO can use an existing Windows sign-in through WIA or an Entra sign-in. Administrative issuance is configurable, but keyONE explicitly advises against it.
- HSM optional, key protection required
- Sensitive x.ID secrets are stored encrypted. An HSM can protect the private key of the protection certificate. Without an HSM, the certificate is used through the local Windows certificate store; this does not provide equivalent hardware protection.
- Native directory integration
- The native Azure Connector accesses Microsoft Entra ID directly through Microsoft Graph, without requiring AD synchronization. For Entra CBA it maintains SKI mappings in certificateUserIds. Entra FIDO2 pre-provisioning combines tenant registration with a separate personal PIN handover.
- One Core and a tested recovery plan
- keyONE recommends one Core with planned rebuilding as the regular starting point. Special availability requirements are assessed within the project. Multi-Core operation is not a generally recommended standard setup; CAs, directories and revocation remain part of availability planning.
EVIDENCE & BOUNDARIES
What the first rollout should demonstrate.
A successful start proves the operating model, not only the installation.
Controlled enrolment
Identity, hardware and policy are evaluated before credentials become active.
Recoverable lifecycle
The small setup also combines revocation and CRL publication with cleanup of connected certificate and directory targets. Issuance, renewal and secure replacement belong to the same lifecycle.
Documented growth path
The next CA, directory, site or outpost can be added without replacing the lifecycle concept.
Directory state from day one
AD publication, strong SKI mapping and native Entra state remain connected to the hardware, identity and credential.
RELATED PRODUCT
SYNRION x.ID
Manage YubiKeys, identities, PIV certificates and FIDO2 centrally in a browser. SYNRION x.ID combines native Entra integration with cloud, on-premises or hybrid deployment through Outpost connectors. The portal also supports mobile access; the feature overview states release status and requirements.
THE NEXT CONTROLLED STEP
Start with the smallest deployment that can be operated securely.
We will define a bounded first use case, the required trust controls and a growth path that fits your existing infrastructure.