Security is architecture,
not a feature.
KeyShare's security posture is built into how the platform works — not layered on after the fact. This page describes the architectural properties, standards compliance, and data handling practices that protect identity data across every deployment.
Last updated: March 2026
Executive Summary
KeyShare uses government-grade cryptography (FIPS 140-2 validated). Biometric face data is processed on-device and immediately discarded — it never reaches the cloud and is never stored. Data residency is configurable for every deployment. The Puck hardware includes secure boot, signed firmware updates, and tamper detection. Our architecture aligns with SOC 2, ISO 27001, GDPR, HIPAA, and NIST CSF requirements. We don't claim certifications we haven't earned — we describe the architectural properties that support your compliance.
On This Page
Table of Contents
Five architectural principles.
Data Minimization by Design
Collect only what's needed. Process it where it's needed. Discard it when it's done. Verifiers receive only the specific claims they require, not a full identity payload. In physical access, the reader receives zero PII. In visitor management, biometric data is processed in RAM and discarded in under one second.
On-Device Processing & Offline Security
The most sensitive operations happen on-device, not in the cloud. Biometric matching runs on the Puck's CPU. Digital ID verification is performed locally via NFC. In physical access, the Panel Application runs on the Mercury controller — access decisions are made on-premise with zero cloud dependency.
Cryptographic Trust, Not Perimeter Trust
Identity verification is based on cryptographic proof, not network position. Every credential is verified against the issuing authority's certificate chain. A mobile driver's license is verified against the state DMV's signing key. The Puck doesn't trust a credential because it arrived from a trusted network — it trusts it because the math checks out.
Architectural Compliance
Compliance is a property of the architecture, not a certification badge. No vendor can certify you into compliance. KeyShare provides an architecture whose properties align with SOC 2, ISO 27001, GDPR, ITAR, HIPAA, SOX, and FISMA/FedRAMP requirements.
Transparency
Security through obscurity is not security. Government and enterprise security teams can audit KeyShare's application and service layer source code. Cryptographic mechanisms use published, peer-reviewed standards (ISO 18013-5, FIDO2, W3C VCs, OSDP v2.2). Key management uses PKCS#11 interfaces to industry-standard HSMs. No proprietary black-box cryptographic implementations.
What we implement. What we align with. What we don't claim.
KeyShare implements specific cryptographic and identity standards. Our architecture aligns with industry security frameworks. We do not claim certifications that are deployment-specific.
Implemented Standards
| Standard | Scope | Detail |
|---|---|---|
| ISO 18013-5 | Digital ID verification | mDL and digital ID reading, verification, and data extraction via NFC. Cryptographic signature validation against issuing authority certificates. |
| OSDP v2.2 | Reader-panel communication | Secure Channel Protocol for encrypted, authenticated, bidirectional communication between NFC readers and access control panels. |
| FIPS 140-2 | Cryptographic operations | Validated via wolfSSL cryptographic library. Covers TLS, AES-256, ECDSA, ECDH operations across the Puck, Panel Application, and server-side services. |
| ISO 19790 | Intl. crypto module | International equivalent of FIPS 140 — for deployments outside US/Canada jurisdictions. Same PKCS#11 interface. |
| W3C VCs | Government credentials | Credential issuance, presentation, and verification using W3C VC Data Model for government deployments. |
| FIDO2 / WebAuthn | Authentication | Passkey-based authentication for platform access. Hardware-bound credentials stored in device TEE/Secure Enclave. |
| MISRA C:2012 | Embedded firmware | Reader Library embedded firmware follows MISRA C:2012 coding standards for safety-critical embedded systems. |
Architectural Alignment
| Framework | Relevant Architectural Properties |
|---|---|
| SOC 2 Type II | On-premise access decisions (CC6.1). Manifest signing with ECDSA (CC6.7). Comprehensive audit logging (CC7.2). mTLS between services (CC5.2). RBAC enrollment workflows (CC6.2). |
| ISO 27001 | Data minimization (A.8.11). FIPS 140-2 cryptographic controls (A.8.24). RBAC + MFA access control (A.8.3). Logging and monitoring (A.8.15). |
| GDPR | Selective disclosure (Art. 5(1)(c)). Purpose limitation (Art. 5(1)(b)). Configurable retention (Art. 5(1)(e)). Data residency per tenant (Art. 44-49). Right to erasure (Art. 17). |
| ITAR | On-premise access decisions with no cloud dependency. FIPS 140-2 cryptography. Non-reversible identity binding. Full audit trail. US data residency. |
| HIPAA | Data minimization via selective disclosure (§164.502(b)). No PII at reader (§164.312(a)). Audit logging (§164.312(b)). Encryption in transit and at rest (§164.312(e)). |
| SOX | Tamper-resistant audit logging (§302). Non-transferable identity binding (§404). Access rule enforcement (§802). |
| FISMA / FedRAMP | FIPS 140-2 validated cryptography. On-premise manifest with no PII in transit. Audit logging with SIEM export. Configurable data residency. |
| NIST CSF | Identify: asset classification, risk assessment. Protect: FIPS crypto, access control. Detect: audit logging, anomaly detection. Respond/Recover: incident procedures, offline architecture. |
| PCI-DSS | KeyShare does not process, store, or transmit cardholder data. Payment transactions are tokenized and routed directly to PCI-DSS certified processors. KeyShare systems handle only tokenized references. |
What We Do Not Claim
- We do not claim SOC 2 Type II certification. SOC 2 is earned per deployment through a third-party audit — not per vendor.
- We do not claim ISO 27001 certification at the company level. Individual deployments may pursue ISO 27001 certification.
- We do not claim HIPAA compliance. HIPAA compliance is per covered entity. Our architecture aligns with HIPAA security controls.
- We do not claim "GDPR compliance" as a blanket statement. GDPR compliance is per deployment and per controller.
- We do not claim FedRAMP authorization. FedRAMP is per cloud service offering. Contact us to discuss federal deployment requirements.
Published standards. Validated implementations. No proprietary cryptography.
Every cryptographic operation in the KeyShare platform uses published, peer-reviewed algorithms implemented in validated libraries. There are no proprietary or custom cryptographic implementations.
Cryptographic Primitives
| Operation | Algorithm | Implementation |
|---|---|---|
| Digital signatures | Ed25519 (EdDSA), ECDSA P-256 | wolfSSL (FIPS 140-2 validated) |
| Key exchange | X25519 (ECDH), ECDH P-256 | wolfSSL |
| Symmetric encryption | AES-256-GCM | wolfSSL |
| Hashing | SHA-256, SHA-512 | wolfSSL |
| TLS | TLS 1.3 | wolfSSL |
| Certificate management | X.509 v3 | wolfSSL, platform PKI |
| Credential proof format | DataIntegrityProof (eddsa-rdfc-2022) | Platform Crypto Library |
Key Management
| Key Type | Storage | Rotation | Notes |
|---|---|---|---|
| Issuer signing keys | HSM (PKCS#11) | Annual or on compromise | Keys never exist outside HSM unencrypted |
| Service TLS keys | HSM or managed KMS | Annual | mTLS between all services |
| DID authentication keys | HSM | Biennial or on compromise | Per DID Document specification |
| Wallet signing keys | Device TEE / Secure Enclave | On device change | Hardware-bound, never extractable |
| Manifest signing | HSM-derived | Per sync cycle | ECDSA signature on every manifest |
| Session keys | Ephemeral (in memory) | Per session | Derived via ECDH, never persisted |
HSM Integration: KeyShare's server-side cryptographic operations use a PKCS#11 interface supporting multiple HSM backends — AWS CloudHSM, Azure Dedicated HSM, Thales Luna, Utimaco SecurityServer, and SoftHSMv2 (development/testing only). The PKCS#11 abstraction enables deployment-time HSM selection with zero code changes.
The Puck sits in your lobby. Here's how it's protected.
The KeyShare Puck is deployed in semi-public spaces. Physical access to the device is assumed in the threat model. The device is designed to resist tampering, protect cryptographic keys, and remain trustworthy even if an attacker has physical access.
| Security Property | Implementation |
|---|---|
| Secure boot | Firmware integrity verified at every boot via a cryptographic chain of trust. If the boot image fails signature verification, the device refuses to start and reports a tamper event. |
| Signed firmware updates | All firmware updates are cryptographically signed. Unsigned or tampered firmware is rejected. Rollback protection prevents downgrading to older, potentially vulnerable versions. |
| Key storage | Cryptographic keys stored in the device's secure element — hardware-isolated, never extractable via software. Keys are generated in the secure element and never leave it unencrypted. |
| Tamper detection | Hardware tamper detection triggers key zeroization (secure erasure of all cryptographic material) and device lockout. A tampered Puck cannot be used until re-provisioned. |
| Compromise response | A Puck reported lost, stolen, or compromised can be remotely revoked via the device management console. Revocation removes trust credentials. Re-provisioning requires physical access plus administrator authentication. |
| Firmware delivery | Updates delivered over HTTPS (TLS 1.3) from KeyShare's signed update server. Update events are logged (device ID, firmware version, timestamp, result). |
What we collect, where it lives, how long it stays.
Data in Transit
All data in transit is encrypted with TLS 1.3. Internal service-to-service communication uses mutual TLS (mTLS) with certificate-based authentication. No plaintext data is transmitted between any KeyShare components.
Data at Rest
All data at rest is encrypted with AES-256. Database encryption uses provider-managed keys (AWS KMS) or customer-managed keys (for government and enterprise deployments requiring key custody).
Data Residency
| Deployment Context | Data Location | Configuration |
|---|---|---|
| Website (keyshare.id) | US (AWS) | Fixed |
| Hotel deployments (GEP) | Per-property config | US, EU, or regional |
| Building access (Connect) | Per-tenant config | US, EU, UK |
| Visitor management (VEP) | Per-site config | US, EU, UK, other on request. Biometric data never leaves device. |
| Government (DPI) | Sovereign deployment | In-country deployment with data isolation. No cross-border transfer without explicit config. |
Network Security
Business Continuity & Disaster Recovery
| Component | Availability Approach |
|---|---|
| On-premise access (PACS) | No cloud dependency. Doors continue normally during any cloud outage. Panel Application caches the signed manifest locally. |
| On-device verification (Puck) | No cloud dependency. NFC credential reading and cryptographic validation are fully local. |
| Cloud services | Multi-AZ deployment with automated failover. Database replication across AZs. Automated daily backups. |
| Disaster recovery | RPO < 1 hour (last backup). RTO < 4 hours (service restoration). Custom DR configurations available for government and enterprise. |
Data Minimization by Vertical
Guest Experience Platform (Hotel)
Only verification result, guest name, and reservation match are passed to the GEP. Full credential payload is not stored. Wallet keys delivered to guest's mobile wallet. No data persists on Puck after interaction.
Building Access (KeyShare Connect)
Zero PII at reader edge. Panel Application derives a non-reversible, site-specific UUID. Cross-site tracking is architecturally impossible because UUIDs are site-specific.
Visitor Experience Platform (VEP)
Face matching runs in Puck RAM only — never written to disk, never transmitted. Only verification result and extracted name passed to VEP. Automatic deletion per retention policy.
Government (DPI)
Selective disclosure — verifiers receive only specific claims. Age confirmation returns yes/no, not a date of birth. Citizen data controlled by the deploying government's schema.
Every event. Every access. Every credential.
KeyShare generates comprehensive, tamper-resistant audit logs across all deployment types.
| Event Category | Examples | Storage |
|---|---|---|
| Identity verification | Credential presented, verification result, issuing authority, timestamp | Platform audit log |
| Credential delivery | Credential type, delivery method, recipient device, timestamp | Platform audit log |
| Access events (PACS) | Door ID, credential presented, access rule matched, grant/deny | Customer's existing PACS |
| Enrollment events | User enrolled, method (mDL or manual), timestamp, admin | KeyShare Connect |
| Revocation events | User revoked, method, timestamp, revoking admin | Connect + PACS |
| Administrative actions | Configuration changes, role assignments, policy updates | Platform audit log |
| System events | Manifest sync, firmware updates, connectivity status | Platform audit log |
Log Properties
- Tamper-resistant (append-only, cryptographically signed)
- Exportable in standard formats for SIEM integration (Splunk, Elastic, Sentinel)
- Configurable retention per deployment and per data category
- PII masked in system logs — personal identifiers never exposed in operational logs
- Access to audit logs is role-restricted and itself logged
Defined procedures. Defined timelines. Defined accountability.
KeyShare maintains documented incident response procedures covering detection, containment, investigation, notification, and recovery.
Detection
Automated monitoring and alerting for security anomalies. Alert severity classification (Critical, High, Medium) with defined escalation procedures.
Containment
Immediate containment including service isolation, credential revocation, and affected-device quarantine.
Notification
Notifications within 24 hours of confirmed incident. For personal data: 72 hours under GDPR, "without unreasonable delay" under US state laws.
Post-Incident Review
Root cause analysis and remediation documentation for every security incident. Remediation evidence shared with affected customers.
Penetration testing: KeyShare engages independent third-party security firms for periodic penetration testing. Test reports and remediation evidence are available under NDA. Contact ….
Vulnerability Disclosure Program
| Property | Detail |
|---|---|
| Report | … |
| Acknowledgment | We acknowledge receipt within 2 business days. |
| Assessment | Initial severity assessment within 10 business days. |
| Scope | In scope: keyshare.id, APIs, Puck firmware, cloud services, mobile SDKs. Out of scope: third-party services, social engineering, denial-of-service testing. |
| Safe harbor | We will not pursue legal action against researchers who report vulnerabilities in good faith and avoid accessing customer data. |
| Coordination | 90-day remediation window before public disclosure. |
Patent-protected architecture.
KeyShare's identity verification and credential delivery technology is protected by four granted US patents, with additional US and international patents pending. The patent portfolio covers the core interaction model — NFC-based identity verification, credential provisioning, and the orchestration layer that connects identity verification to downstream systems.
Government-inspectable code.
For government and enterprise deployments, KeyShare's application and service layer source code is available for security audit. The code your organization runs is the code your security team can read.
| Component | Auditability | Notes |
|---|---|---|
| Backend services | Full source code available | All code that processes identity data |
| Mobile SDK | Full source code available | All code running on citizen/employee devices |
| Workflow engine | Full source code available | Workflow definitions, schema configurations |
| Orchestration engine | Compiled binary + documented APIs | Proprietary core IP — interfaces allow integration verification |
| Credential derivation | Compiled binary + documented APIs | Proprietary cryptographic derivation — covered by granted patents |
To request a code audit engagement, contact ….
What's in the software. Where it comes from. How it's verified.
KeyShare maintains supply chain security practices across platform services, device firmware, and mobile SDKs.
| Practice | Implementation |
|---|---|
| Dependency management | All third-party dependencies tracked, version-pinned, and monitored for known vulnerabilities via automated CI/CD scanning. |
| Vulnerability scanning | Automated scanning on every build. Critical and high-severity vulnerabilities remediated before release. |
| Signed builds | Platform releases and firmware updates are cryptographically signed. Build provenance is traceable to the specific source commit and pipeline run. |
| SBOM availability | Software Bill of Materials (CycloneDX or SPDX) available upon request during enterprise evaluation. |
| Open-source licensing | All open-source components reviewed for license compatibility. Obligations tracked and satisfied. |
| Firmware supply chain | Puck firmware dependencies minimized. Reader Library uses MISRA C:2012. Firmware binaries signed and verified at every stage. |
To request an SBOM or discuss supply chain practices, contact ….
Questions about our security posture?
Our team is available for detailed security architecture discussions, compliance alignment reviews, and code audit engagements.
Last reviewed: March 2026