Employee Onboarding Flow
Overview
GetTrusted's Employee Onboarding Flow creates hardware-backed enterprise device keys with dual-signed X.509 certificates for employees joining an organization. This flow combines personal identity management with organizational credentialing, resulting in a cryptographically verifiable chain of trust from the employee's hardware device through the organization's Certificate Authority.
Key Security Features:
Dual-Signature X.509 Certificates: Co-signed by employee's device key AND organization CA
Hardware-Backed Enterprise Keys: Generated in Secure Enclave/StrongBox/TPM (never exported)
OIDC Directory Integration: Employee identity validated via company SSO (Okta, Azure AD, etc.)
AWS KMS Protected CA: Organization CA private keys encrypted at rest in hardware security modules
Managed Data Sync: Automatic synchronization of employee persona and organizational contacts
Certificate Lifecycle: 365-day validity with automatic renewal support
Process Overview
Diana (a new employee at Acme Corp) has already authenticated via OIDC (Organization Signup Flow). Now she needs to create an enterprise device key that will be used for all organizational communications and access.
Diana's Perspective (New Employee)
Backend Perspective (GetTrusted API + Organization CA)
Process Flow Diagram
sequenceDiagram
participant Diana Device
participant Diana Secure Enclave
participant GetTrusted Backend
participant AWS KMS
participant Organization CA
participant OIDC Directory
Note over Diana Device,OIDC Directory: Phase 1: Prerequisites (OIDC Complete)
Diana Device->>Diana Device: Has OIDC completion:<br/>{id_token, directory_id, organization_id}
Diana Device->>Diana Device: Check enterprise key capability
Note over Diana Device,OIDC Directory: Phase 2: Enterprise Key Generation
Diana Device->>Diana Secure Enclave: Generate enterprise key pair (P-256)
Diana Secure Enclave-->>Diana Device: {public_key, private_key_ref}
Note right of Diana Secure Enclave: Private key NEVER leaves hardware
Diana Device->>Diana Device: Create X.509 TBS certificate<br/>Subject: O=Acme, CN=diana.prince
Diana Device->>Diana Secure Enclave: Sign TBS with device key (1st signature)
Diana Secure Enclave-->>Diana Device: Device signature
Diana Device->>GetTrusted Backend: POST /enterprise-keys/create<br/>{public_key, TBS, device_signature, id_token}
Note over Diana Device,OIDC Directory: Phase 3: Backend Certificate Signing
GetTrusted Backend->>GetTrusted Backend: Verify OIDC ID token (JWT)<br/>Validate claims (sub, email, exp)
GetTrusted Backend->>GetTrusted Backend: Verify device signature on TBS
GetTrusted Backend->>GetTrusted Backend: Get organization CA from Firestore
GetTrusted Backend->>AWS KMS: Decrypt organization CA private key
AWS KMS-->>GetTrusted Backend: CA private key (plaintext)
GetTrusted Backend->>Organization CA: Sign TBS with CA key (2nd signature)
Organization CA-->>GetTrusted Backend: CA signature
GetTrusted Backend->>GetTrusted Backend: Assemble X.509 certificate:<br/>{TBS, device_sig, ca_sig}
GetTrusted Backend->>GetTrusted Backend: Build certificate chain:<br/>[Enterprise, Org CA, Business CA, Root CA]
GetTrusted Backend->>GetTrusted Backend: Store in Firestore:<br/>/enterprise_device_keys/{key_id}
GetTrusted Backend-->>Diana Device: {certificate, certificate_chain, key_id, expires_at}
Note over Diana Device,OIDC Directory: Phase 4: Certificate Installation
Diana Device->>Diana Secure Enclave: Install certificate with private key ref
Diana Secure Enclave-->>Diana Device: Certificate installed
Diana Device->>Diana Device: Validate certificate chain<br/>Verify both signatures
Diana Device->>Diana Device: Store metadata in SQLite
Note over Diana Device,OIDC Directory: Phase 5: Managed Data Sync
Diana Device->>GetTrusted Backend: GET /enterprise/personas/managed
GetTrusted Backend->>OIDC Directory: Fetch employee data (via OIDC)
OIDC Directory-->>GetTrusted Backend: {name, email, job_title, department}
GetTrusted Backend-->>Diana Device: Managed persona (read-only)
Diana Device->>Diana Device: Store managed persona locally
Diana Device->>GetTrusted Backend: GET /enterprise/contacts/managed
GetTrusted Backend->>OIDC Directory: Fetch org colleagues
OIDC Directory-->>GetTrusted Backend: List of organizational contacts
GetTrusted Backend-->>Diana Device: Managed contacts
Diana Device->>Diana Device: Store managed contacts<br/>Set up 24hr auto-syncCryptographic Security
Dual-Signature X.509 Certificate
TBS Certificate Structure:
Version: 3 (X.509v3)
Serial Number: {unique_serial}
Signature Algorithm: ECDSA-with-SHA256
Issuer: O=Acme Corporation, CN=Acme GetTrusted CA
Validity:
Not Before: 2025-01-10 00:00:00 UTC
Not After: 2026-01-10 00:00:00 UTC
Subject: O=Acme Corporation, OU=Employee, CN=diana.prince, [email protected]
Subject Public Key Info:
Algorithm: id-ecPublicKey (P-256)
Public Key: {p256_ecdsa_public_key}
Extensions:
basicConstraints: CA:FALSE
keyUsage: digitalSignature
extendedKeyUsage: clientAuth, emailProtection
subjectAltName: email:[email protected]Dual Signature Structure:
signatureAlgorithm: ECDSA-with-SHA256
signatureValue:
device_signature: {ecdsa_signature_from_device_key} # First signature
ca_signature: {ecdsa_signature_from_org_ca} # Second signatureCertificate Chain Validation
Full PKI Hierarchy:
1. GetTrusted Root CA (Self-Signed)
├─ Subject: O=GetTrusted, CN=GetTrusted Root CA
├─ Key Usage: Certificate Signing, CRL Signing
├─ Validity: 20 years
2. GetTrusted Business CA (Signed by Root CA)
├─ Subject: O=GetTrusted, CN=GetTrusted Business CA
├─ Issuer: GetTrusted Root CA
├─ Key Usage: Certificate Signing, CRL Signing
├─ Validity: 10 years
3. Acme Corporation CA (Signed by Business CA)
├─ Subject: O=Acme Corporation, CN=Acme GetTrusted CA
├─ Issuer: GetTrusted Business CA
├─ Key Usage: Certificate Signing, CRL Signing
├─ Basic Constraints: CA:TRUE, pathlen:0
├─ Validity: 10 years
4. Diana's Enterprise Device Certificate (Signed by Acme CA + Device Key)
├─ Subject: O=Acme Corporation, OU=Employee, CN=diana.prince
├─ Issuer: Acme Corporation CA
├─ Key Usage: digitalSignature
├─ Dual Signatures: [Device Key, Org CA]
├─ Validity: 365 days (1 year)Security Guarantees
Hardware-Backed Enterprise Keys
Enterprise private keys never leave Secure Enclave/StrongBox/TPM
Key generation happens entirely in hardware security module
Private keys cannot be extracted or exported
Dual-Signature Verification
TWO independent signatures on same TBS certificate
Device signature proves delegation from personal identity
Organization CA signature proves organizational authorization
Both must be valid for certificate to be trusted
OIDC Directory Integration
Employee identity validated via company SSO
Directory ID from OIDC
subclaim (unique, immutable)Email verification required (
email_verified: true)JWT signature verification prevents token tampering
AWS KMS Key Protection
Organization CA private keys encrypted at rest
Decryption requires IAM authentication
Audit logging for all key usage
Automatic key rotation supported
Certificate Chain Trust
Full PKI validation from device through organization to root
Each link in chain cryptographically verified
Expired certificates automatically rejected
Certificate revocation supported (future enhancement)
Managed Data Security
Employee persona data read-only (cannot be tampered)
Organizational contacts auto-synced from directory
Data freshness guaranteed via periodic sync
Access controlled via enterprise key
Production Resilience
Automatic retry with exponential backoff (1s, 2s, 4s)
30-second timeout for enterprise key creation
Smart error classification (never retry implementation failures)
Immediate managed data sync after key creation
Strategic Implications
Enterprise Identity Lifecycle
Before GetTrusted:
- Manual employee onboarding with IT support
- Physical hardware tokens or smart cards required
- No cryptographic binding to personal identity
- Separate credentials for each enterprise appWith GetTrusted:
- Automatic onboarding via OIDC SSO
- Hardware-backed enterprise keys (no physical tokens)
- Cryptographically bound to employee's personal device identity
- Single enterprise credential for all GetTrusted organizational featuresCertificate-Based Access Control
Dual-Signature Benefits:
Delegation Proof: Device signature proves employee authorized this enterprise key
Authorization Proof: Org CA signature proves organization authorized this employee
Non-Repudiation: Both parties cryptographically committed to relationship
Automatic Revocation: Organization can revoke CA signature without affecting device
Organizational Trust Hierarchy
Trust Levels:
1. Maximum Trust: P2P trust establishment + hardware attestation
2. High Trust: Phone number ownership + remote attestation
3. Organizational Trust: Enterprise OIDC + dual-signed certificate ← Employee Onboarding
4. Business Trust: Business certificate + entity verification
5. Unverified: Contact information onlyOrganizational Trust Grants:
Access to organizational shared resources
Managed persona and contacts (auto-synced)
Enterprise messaging and verification
Organizational compliance features
Last updated