Teams running many internal applications
Each application stops keeping its own user table, password store and settings file. People sign in one way, and secrets and settings live in one place.
Identity, credential and access management
One place for who signs in, and what they can reach.
EDCS (Enterprise Directory and Configuration Store) gives your applications one sign-on service, one directory of people and groups, one encrypted vault for secrets and one store for settings and feature flags, run from an admin console. It runs on your own servers, or we host it for you.
Built and tested, with most security features off until you switch them on. What is not included is listed plainly below.
See it working
Narrated walkthroughs of the product.
Recorded on a test installation with demo data: the people and organizations are fictional. Captions are on by default, and each video has a transcript.
A tour of EDCS
The directory, single sign-on, second factors, the secrets vault, application settings and access governance, in about a minute and a half.
Watch in 1080p: A tour of EDCS (MP4, 3.3 MB)
Read the transcript: A tour of EDCS
This is EDCS, the Enterprise Directory and Configuration Store. It keeps your people, their access, and your application secrets in one place. It can run on servers you control, and serve several organizations without mixing their data. The directory holds people and groups, and your applications look them up through one service. People sign in once, on one hosted page, and move between applications. Each organization decides whether to require a second factor, a passkey, or a smart card. Partner applications connect through federation, and each one receives only the attributes you release. Each version of a secret is encrypted under its own key, and every read is recorded. Application settings and feature flags live beside them, and a setting can point at a secret. Governance keeps a record of who holds which access in each application, and who granted it. Rules keep conflicting duties apart, such as entering a payment and approving it. Owners reconfirm access on a schedule, and unconfirmed access can be removed at the deadline. Changes are recorded in the audit trail: who, what, when, and whether it was allowed. These features are built, and switched on organization by organization. EDCS is not yet running in our own production. Your people, your secrets and your records, on servers you control. This is EDCS.
From sign-in to an access review
One person signs in with a second step and asks for access, the application owner approves it, a scheduled review confirms it, and the audit trail records each step.
Watch in 1080p: From sign-in to an access review (MP4, 4.0 MB)
Read the transcript: From sign-in to an access review
Alex Rivera opens the case portal and lands on the organization's sign-in page. Alex can use a password, a passkey, a smart card, or a partner organization's sign-in. Alex types a password. This organization also requires a second step. A code from an authenticator app, or a security key, completes the sign-in. Inside, Alex asks for the access the work needs, with a reason and an end date. The request waits for an approver. Nothing is granted yet. Jordan Lee owns the application, and sees the request with its reason. Before anything is granted, EDCS checks the request against the separation-of-duties rules. Jordan records a reason and approves. The reason is kept with the decision. Later, a scheduled access review asks Jordan to confirm that Alex still needs it. Jordan confirms it with a note. Access nobody confirms can be removed at the deadline. Each step is in the audit trail: who acted, on what, when, and the outcome. These features are built, and switched on organization by organization. They are not yet running in our own production. Sign-in, requests, approvals and reviews, in one record. This is EDCS.
Who it is for
Stop rebuilding sign-in in every application.
Most organizations end up with a user table, a password store and a settings file inside each application. EDCS replaces those with one set of services that every application calls.
Organizations that keep identity in-house
Run the directory, the sign-on service and the vault on servers you control, under your own security plan, instead of renting them from a cloud identity provider.
Providers serving several organizations
One installation, with each organization’s people, secrets and settings in their own databases.
Screens
What your people and administrators see.
The product’s own sign-in pages and admin console, captured on a test setup with demo data: the people, the organization and its partners are fictional. Select Full size under any screen to open it at full resolution.
Sign-in
Admin console
Governance
Federation
Available now
What you can run today.
These 34 capabilities are built and included in EDCS today, and covered by automated tests. Most security features are off by default and are switched on per organization. A card marked “Test installation only” is not yet running in our own production.
Sign-in and single sign-on
OAuth 2.0 and OpenID Connect sign-on service
Issues signed access tokens to your applications under the OAuth 2.0 and OpenID Connect (OIDC) standards. A discovery document lets an application find the endpoints and signing keys on its own. Supports the password, refresh-token and client-credentials grants.
Two-factor sign-in
Time-based one-time password (TOTP) codes from an authenticator app, single-use backup codes issued at enrollment, and trusted devices that each person can list and revoke.
Magic-link sign-in
A one-time sign-in link sent by email. The link returns people only to addresses on your allowlist.
Short-lived tokens
Access tokens are short-lived and are renewed with refresh tokens, so a leaked token has a short useful life. Every directory, vault and configuration application programming interface (API) call needs a valid token that carries the right scope.
Browser single sign-on with PKCE
A hosted sign-in page and the authorization-code flow with Proof Key for Code Exchange (PKCE), so people sign in once in the browser and move between applications without handing each one their password.
Test installation only
CAC and PIV smart-card sign-in
Sign-in with a Common Access Card (CAC) or Personal Identity Verification (PIV) card certificate, with certificate revocation checking that refuses the sign-in when the revocation status cannot be confirmed. Per organization, it also accepts partners’ PIV-Interoperable (PIV-I) cards and derived PIV credentials on mobile devices.
Test installation only
SAML 2.0 federation
An identity provider for applications that sign in with Security Assertion Markup Language (SAML) 2.0, with a registry of the partners you trust and the attributes each one receives.
Test installation only
Security keys and passkeys
Fast IDentity Online 2 (FIDO2) and Web Authentication (WebAuthn) security keys and passkeys, as the second factor after a password or, per organization, for passwordless sign-in. An organization can require a phishing-resistant factor.
Test installation only
Assurance levels and step-up
Every user token states how the person signed in and carries the authenticator assurance level (AAL1, AAL2 or AAL3) that EDCS computes from the factors it verified, mapped to National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63B Revision 3. Whether a deployment meets a level is your assessor’s decision. An application can demand a higher level, or a fresh sign-in, before a sensitive action.
Test installation only
Sign-in through partner organizations
People from a partner organization sign in with their own organization’s identity provider, over OpenID Connect or SAML 2.0. Their accounts are linked by an administrator, not automatically.
Test installation only
Sessions, token services and sign-out
Token introspection and revocation, a user-information endpoint, sign-out that reaches the other applications in the session, and administrator revocation of a person’s sessions. The session idle timeout is on by default at 15 minutes and is set per organization and per application.
Test installation only
Sign-in notice and consent
An optional notice that people must acknowledge before they are asked for a credential, with each acknowledgment recorded. Off by default.
Test installation only
Directory and provisioning
Directory with an API
People and groups live in a Lightweight Directory Access Protocol (LDAP) directory, and your applications read and manage them through a web API instead of speaking LDAP themselves.
SCIM 2.0 provisioning
A System for Cross-domain Identity Management (SCIM) 2.0 endpoint, so an authoritative source such as a human-resources system can create, change and deactivate people and groups without a person retyping them.
Test installation only
Outbound provisioning
Changes to people and their access are pushed to downstream applications by SCIM or by a signed notification, through a durable queue with retries and a list of failed deliveries that an administrator can retry or dismiss.
Test installation only
Attribute-based access rules
Rules grant access from a person’s attributes, such as their organization, and each application receives only the attributes you release to it.
Test installation only
Secrets and application configuration
Envelope-encrypted secrets vault
Each version of a secret is encrypted under its own 256-bit data key, and that key is encrypted under a key-encryption key that is never written to disk unencrypted. Earlier versions are kept, so a change can be traced and rolled back.
Central application configuration and feature flags
Settings and feature flags for each application, kept in one place. A setting can point at a vault secret: the value is fetched when an application with permission to read it asks, and is never copied into the configuration.
Per-application service clients
Each application gets its own client identity with only the scopes it needs, so one application cannot read another’s secrets or settings.
Service clients without shared secrets
An application can authenticate with a signed assertion (private_key_jwt) or with a client certificate over mutual Transport Layer Security (mTLS), and receives tokens bound to that certificate.
Test installation only
Governance and audit
Audit events
Directory sign-in attempts, secret reads and changes, and configuration changes are recorded with who, what, when, the source address, and whether it succeeded.
Entitlement record with attestation and reattestation
One record of who holds which access in each application, with history. An accountable owner confirms that access is correct when it is granted, and again on a schedule; access that is not reconfirmed by the deadline is removed.
Test installation only
Separation of duties
Rules that stop one person from holding two roles that must stay apart, such as entering a payment and approving it.
Test installation only
Access requests with approval
People ask for access and an owner approves or denies it, optionally with a second approver. Access can carry an end date, and separation-of-duties rules still apply to an approved request.
Test installation only
Access decisions for your applications
A policy decision point that an application can ask whether a person may do something: role-based rules with attribute conditions, and a refusal unless a rule allows it.
Test installation only
Tamper-evident audit trail and SIEM export
Each audit record is linked to the one before it by a SHA-256 hash, so an edited, deleted or missing record is detected by the verification check (deletion of the newest records shows only against the SIEM copy), and optional checkpoints keyed with a hash-based message authentication code (HMAC) catch a rewritten chain. Records can be sent to your security information and event management (SIEM) system as they are written; export is off by default.
Test installation only
Keys, cryptography and availability
FIPS mode on the platform’s module
Off by default. When it is on, each service checks at start-up that the operating system’s Federal Information Processing Standard (FIPS) provider is loaded and enforcing, and refuses to start if it is not. EDCS relies on that platform module and claims no validation of its own. The standard images do not include a FIPS provider; a FIPS deployment uses images built on a FIPS-capable base.
Test installation only
Signing keys in a hardware security module
Off by default. With a hardware security module (HSM) reached through Public-Key Cryptography Standards #11 (PKCS#11), token and SAML signing keys are generated on the module and never leave it. If the module cannot be reached, signing stops; EDCS never falls back to a software key.
Test installation only
Signing-key rotation
Token and SAML signing keys roll over with the next key published before it signs, and the old key kept, signing nothing, while what it signed is still in use. Administrators can also rotate on demand, or revoke all of an organization’s keys after a compromise.
Test installation only
Several instances within one site
Every service can run as several instances behind a load balancer, sharing sessions, keys, lockout counters and rate limits through the database. Replication between data centers is not included.
Test installation only
Administration and organizations
Admin console
A web console for organizations, people, groups, application clients, secrets, configuration and two-factor settings. Its demonstration-data reset, for applications that offer one, does nothing until an administrator lists the hosts allowed to receive it.
Administrator sign-in as a user (Quick Login)
An organization’s administrator can open a registered application signed in as one of that organization’s people, to see what they see. The session gets that person’s access, never the administrator’s, through a token that lasts 5 minutes by default and cannot be refreshed. The token is marked as impersonation and carries the administrator’s own assurance level, and an application’s access rules still apply. Each token issued is audited, and so is each one refused because the caller is not an administrator or the person may not use the application. It is available to the organization’s administrators and has no separate switch.
Multiple organizations, kept apart
Each organization gets its own databases and its own branch of the directory, selected by web address or organization code, so one installation can serve several organizations without their data mixing.
Delegated administration
Delegates scoped to particular applications, who can grant and remove access to those applications and nothing else. A delegation can expire and be withdrawn, a delegate cannot grant access to themselves, and every delegated action is audited.
Test installation only
Standards and architecture
Open standards, small services.
Sign-in, federation and provisioning use published standards (OpenID Connect, OAuth 2.0, SAML 2.0, SCIM 2.0). The directory, vault, configuration and access-decision interfaces are EDCS web APIs, documented in the product. The Security and Standards Guide says where each one stops.
OpenID Connect and OAuth 2.0
Authorization code with Proof Key for Code Exchange (PKCE), refresh-token rotation and client credentials. Clients authenticate with a signed assertion (private_key_jwt, Request for Comments (RFC) 7523) or mutual TLS with certificate-bound tokens (RFC 8705). Token introspection (RFC 7662), revocation (RFC 7009) and back-channel logout.
SAML 2.0
An identity provider with signed responses, optional encrypted assertions, signed metadata and single logout, and a service provider for sign-in through a partner organization.
SCIM 2.0
Inbound, so an authoritative source such as a human-resources system keeps the directory current, and outbound, so downstream applications hear about every change.
FIDO2 and WebAuthn
Security keys and passkeys as a second factor, or for passwordless sign-in where an organization turns it on.
PIV, CAC, PIV-I and derived PIV
Chains are built only to the trust anchors you configure. Revocation is checked with the Online Certificate Status Protocol (OCSP), then the certificate revocation list, and the sign-in is refused when status cannot be confirmed. Accepts derived PIV credentials (as defined in NIST SP 800-157) per organization, rated by their own certificate policy. Not yet tested with real cards, phones or partner public key infrastructures (PKIs); tests use a test certificate authority.
NIST SP 800-63B assurance levels
Each user token carries the authenticator assurance level (AAL1, AAL2 or AAL3) that EDCS computes from the factors it verified, mapped to NIST SP 800-63B Revision 3; nothing a client sends can raise it. Whether a deployment meets a level is your assessor’s decision. Step-up on request.
FIPS mode on the platform module
Cryptography goes through the operating system’s library. In FIPS mode each service refuses to start unless the platform’s FIPS provider is loaded and enforcing. EDCS claims no validation of its own. The standard images do not include a FIPS provider; a FIPS deployment uses images built on a FIPS-capable base.
PKCS#11 hardware keys
Token and SAML signing keys generated on a hardware security module, marked not extractable, with no silent fallback to a software key.
Hash-chained audit with SIEM export
Records linked by SHA-256 with HMAC-keyed checkpoints (a keyed hash, not a digital signature), exported as syslog over TLS (RFC 5424 and RFC 5425) in JSON or Common Event Format (CEF), or as JSON over HTTPS.
LDAP directory and TOTP
People and groups in a standard LDAP directory that applications reach through a web API, and authenticator-app codes under RFC 6238 with a replay guard.
How it is put together
- Small services with one job each: a sign-on service, a directory service, a secrets vault, a configuration service and an admin console, on a private network behind your own TLS front end. Every directory, vault and configuration call needs a token with the right scope.
- Each organization gets its own databases and its own branch of the directory.
- Most security features are off by default and are switched on per organization, so an installation changes behavior only when an administrator decides it should.
- Several instances of every service within one site, behind a load balancer. A functional failover test runs two instances of each service and stops one of each part-way through a run of sign-ins; the recorded run finished with no failed operation. It is not a load test.
- Self-hosted, on your servers or in your own cloud account. A deployment template for a US government cloud region (two availability zones, a web application firewall, encrypted storage and a separate mutual-TLS entry point for smart cards) passes offline validation and has not yet been applied to a cloud account.
- A CycloneDX software bill of materials (SBOM) for every container image, and a vulnerability scan that fails on any high, critical or unscored finding not covered by a reviewed, expiring exception. The scan runs on demand today.
Performance
What one installation did under load.
Measured on one shared machine on one evening (November 9, 2026). Read the setup and the limits under the table before using any of these numbers.
The table scrolls sideways to show every column.
Sorting by result orders the rows by their sign-in time; rows without one go last. Every count in the last column is of requests.
| Scenario | Load | Result (95th percentile) | Requests and errors |
|---|---|---|---|
| Weekday load, 60,000-user model (11 minutes) | 5 sign-ins, 22 token refreshes, 20 access decisions and 5 configuration reads a second | Sign-in 104 ms; refresh 75 ms; decision 28 ms; configuration read 27 ms | 0 errors in 47,379 requests |
| Sudden tenfold spike (2 minutes) | 50 sign-ins, 200 access decisions and 50 configuration reads a second | Sign-in 271 ms; back to its earlier level after the spike. Ran with the database connection limit raised; see how it was measured. | 0 errors in 96,433 requests |
| Burst: 60,000 different users sign in within 15 minutes | 66.7 sign-ins a second, plus background traffic | Sign-in 275 ms (99th percentile 707 ms). 57 planned sign-ins (0.09%) were never started during one 3-second slowdown, so the test runner scored a missed target. Memory was at 818 of 1,024 MiB and still rising when the burst ended | 0 errors in 232,914 requests |
| Soak (24 minutes 37 seconds of a planned 30) | Weekday load | Sign-in 116 to 138 ms, with no drift. 4 planned requests were not started as the run was stopped | 0 errors in 106,912 requests |
| Stepped sign-in stress | 20, then 40 sign-ins a second, then part of a step at 60 | Sign-in 69 ms, then 135 ms; 1,080 ms in the 34 seconds at 60 a second, while other jobs loaded the host. An earlier build stalled at 80 a second (95th percentile 27,428 ms), and the fix is in. On the fixed builds the shared host stopped every attempt before the breaking point was found, and no stress run was made on the build with both fixes | 0 errors in 7,134 requests (third attempt) |
| Provisioning (SCIM) | Account lookups and changes in the weekday load; 60,000 accounts created in bulk, one request each | Lookup 3.6 ms; change 28 ms; bulk 295 to 445 accounts a second. Ran with the provisioning rate limit raised; see how it was measured. | 0 errors in 60,000 account-creation requests |
| Cross-check with a second load tool (5 minutes) | The sign-in scenario, 40 simulated users | Agrees with the first tool within run-to-run variation | 0 errors in 7,102 requests |
How it was measured. Measured on November 9, 2026, on one workstation-class machine (16 cores, 32 threads, 62 GiB of memory, solid-state storage) that also ran about 40 other services and the load generator. One instance of each service; the sign-on service was capped at 4 processors and 1 GiB of memory. Plain HTTP inside a private test network, with no TLS or reverse proxy in the path. The directory held 60,000 test users. Sign-in limits, lockout, token lifetimes and audit stayed at their defaults. Two settings differed from a default installation: the database connection limit was raised from 151 to 400 (with the default limit the spike would have run out of connections, so set it above the sum of the connection pools), and the provisioning rate limit was raised for the 60,000-account bulk load. The weekday load is a model of a 60,000-user organization, not a recording of a real site. Times are the 95th percentile unless stated: 95 of 100 requests finished within them. The burst ran on the build that contains both fixes the testing found (November 9, 2026); later builds have not been load-tested. The other rows come from earlier builds, before one or both fixes.
What these figures do not show. These figures show how one small, capped installation behaved on one shared machine. They are not a capacity guarantee and not a measurement of any production deployment. Still to be measured on a dedicated machine: the breaking point, a run of several hours, and every profile with two instances of each service. The sign-on service’s memory use rose steadily under sustained load and had not leveled off when the runs ended, so until a longer run settles it we size that service at 2 GiB or more. Only password sign-in was load-tested: smart-card, SAML and second-factor sign-in, and users who share a few outbound addresses, were not.
Where it runs
On your servers, or hosted by us.
The same EDCS either way. You license it with a base license plus a seat for each person who signs in; prices are on request.
On your own servers
Your hardware, your authorization
We install EDCS on servers you control, in your data center or your own cloud account, and hand your team the runbook. Your identity data stays on your servers.
Hosted by Curtilage
Nothing to install
We run a dedicated installation for you on commercial servers we operate, and handle upgrades, backups and monitoring. Not a government cloud region; see what is not included below.
Product guides
Read the detail, or hand it to your reviewers.
Four guides in PDF, written for the people who evaluate identity products: what is built, how it is deployed, and where each part stops.
EDCS Product Overview
What EDCS is, who it is for, every capability family, where it runs and what is not included.
EDCS Security and Standards Guide
For security reviewers: each standard and where it stops, assurance levels, FIPS mode, hardware keys, the audit chain, hardening, and a NIST SP 800-53 control summary.
Download EDCS Security and Standards Guide (PDF, 10 pages, 207 KB)
EDCS Deployment and Operations Guide
Architecture, single-site high availability, the government cloud template, backup and key recovery, upgrades, monitoring, and the measured performance with its limits.
Download EDCS Deployment and Operations Guide (PDF, 7 pages, 151 KB)
EDCS Accessibility Summary (Draft)
A draft: what the accessibility conformance report covers, how it was tested, the counts by conformance level and the known gaps.
Download EDCS Accessibility Summary (Draft) (PDF, 3 pages, 97 KB)
Before you rely on it
What is not included.
We would rather you hear these from us than find them later.
- No government authorization. EDCS has no Federal Risk and Authorization Management Program (FedRAMP) authorization, no Department of Defense (DoD) Impact Level (IL) authorization at any level, including IL5 and IL6, and no Authority to Operate (ATO). On your servers it runs under your authorization.
- The hosted option is not a government cloud region, and it is not for classified data.
- We do not certify your compliance with any framework. We describe how EDCS is built and configured; your assessor draws the conclusions.
- We do not claim validated cryptographic modules under Federal Information Processing Standard (FIPS) 140-3. In FIPS mode, EDCS relies on the validated module of the operating system it runs on, and whether that module holds a validation certificate depends on your platform.
- The procedure that creates and unlocks the vault’s key-encryption key has not been reviewed for FIPS mode.
- No capacity guarantee. The performance figures on this page come from one shared workstation-class machine running one instance of each service. No load test has yet run with two instances, past the breaking point, or for as long as 30 minutes. We size each deployment with you.
- No replication or failover between data centers. Several instances run within one site.
- The deployment template for a government cloud region has not yet been applied to a cloud account.
- No connectors to DoD enterprise services yet.
- No hosted software-as-a-service (SaaS) offering. There is no shared, sign-up-and-go EDCS; the hosted option is a dedicated installation we operate, arranged per engagement.
- The accessibility conformance report is a draft. It has not yet had a manual pass with screen readers or other assistive technology, and it does not state that EDCS conforms to Section 508 or the Web Content Accessibility Guidelines (WCAG).
- EDCS runs our own applications today; you would be among the first outside organizations to run it.
- Capabilities marked “Test installation only” are built and covered by automated tests but are not yet running in our own production. We demonstrate them on a test installation, with test certificates rather than real smart cards.
See EDCS in a walkthrough.
Tell us how your people sign in today and which applications they use. We’ll show you EDCS, scope where it should run, and quote the license and support that fit.