> ZERO-TRUST // zt-arch-03
Hardware-Bound FIDO2/WebAuthn Enterprise IdP
Zero-password authentication architecture enforcing hardware cryptographic security keys (YubiKey / Secure Enclave) via WebAuthn, mathematically immune to adversary-in-the-middle phishing.
Adversary Threat Model
Adversary deploys reverse-proxy phishing kits (e.g. Modlishka, Evilginx) capturing usernames, passwords, and TOTP verification codes.
Architecture Specs
NIST SP 800-207 Tenets Enforced
- ✓Access to individual enterprise resources is granted on a per-session basis.
- ✓Authentication and authorization are strictly dynamic and strictly enforced before access is allowed.
MITRE ATT&CK Techniques Blocked
3 Maturity Tier Configurations
Evolutionary engineering configurations from baseline Initial up to CISA Optimal zero-compromise fortress.
WebAuthn offered as an optional second factor for privileged admin accounts.
Password + Security Key (FIDO2) fallback to TOTP allowed.
Standard HTTPS TLS 1.3 edge termination.
Authentication success/failure logs retained for 90 days.
Mandatory FIDO2 WebAuthn across 100% of employees; all password inputs removed from UI.
Resident Discoverable Credentials (passkeys) with user presence PIN validation.
Origin validation enforced cryptographically at the browser-token boundary.
Real-time alert on credential registration from non-attested vendor AAGUIDs.
Enterprise-wide hardware-bound passkeys integrated with ephemeral SSH certificates and cloud IAM.
Strict AAGUID allowlisting restricted to FIPS 140-3 Level 3 validated hardware modules.
Cross-origin binding with strict Certificate Transparency monitoring.
Automated cryptographic attestation verification piped to SOC SIEM.
Infrastructure as Code: Terraform & Kubernetes
Production-ready declarative manifests for immediate automated deployment.
resource "keycloak_realm" "realm" {
realm = "tinycto"
enabled = true
web_authn_policy_rp_entity_name = "TinyCTO Enterprise"
web_authn_policy_signature_algorithms = ["ES256", "EdDSA", "RS256"]
web_authn_policy_attestation_conveyance_preference = "direct"
web_authn_policy_authenticator_attachment = "cross-platform"
}apiVersion: v1 kind: ConfigMap metadata: name: webauthn-config namespace: auth data: rp-id: "tinycto.tv" rp-name: "TinyCTO Security Plane" origin: "https://auth.tinycto.tv" user-verification: "required"
Zero-password authentication architecture enforcing hardware cryptographic security keys (YubiKey / Secure Enclave) via WebAuthn, mathematically immune to adversary-in-the-middle phishing.
Architecture Blueprint FAQs
How does the Hardware-Bound FIDO2/WebAuthn Enterprise IdP blueprint mitigate adversary threats and MITRE ATT&CK techniques?
Hardware-Bound FIDO2/WebAuthn Enterprise IdP addresses the following adversary profile: Adversary deploys reverse-proxy phishing kits (e.g. Modlishka, Evilginx) capturing usernames, passwords, and TOTP verification codes. It actively eliminates lateral movement and privilege escalation by mitigating: T1539, T1556, T1110, T1078 via hardware-rooted identity, kernel-level enforcement, or continuous attestation.
Which NIST SP 800-207 Zero-Trust tenets does this architecture enforce?
This blueprint strictly operationalizes the following NIST SP 800-207 tenets: Access to individual enterprise resources is granted on a per-session basis.; Authentication and authorization are strictly dynamic and strictly enforced before access is allowed.. Implicit trust based on network location is replaced with per-session dynamic cryptographic verification.
What are the technical differences between the Initial and Optimal maturity tiers?
The Initial tier focuses on baseline policy and identity enforcement (WebAuthn offered as an optional second factor for privileged admin accounts.), while the Optimal tier delivers CISA ZTMM 2.0 zero-compromise fortress defense (Enterprise-wide hardware-bound passkeys integrated with ephemeral SSH certificates and cloud IAM.) using: step-ca, yubikey-fips, pam-u2f, aws-iam-identity-center.
What is the primary failure mode risk and how is high availability guaranteed?
The primary failure risk is identified as: Hardware security key physical obsolescence cycle management.. Resilience is maintained through active-active control planes, local cached attestations, and graceful degradation playbooks.
How can engineering teams automate this architecture using Terraform and Kubernetes?
The provided declarative Terraform HCL (main.tf) and Kubernetes policy manifests (policy.yaml) can be immediately integrated into automated GitOps CI/CD pipelines (e.g., ArgoCD, Flux) for reproducible, drift-detected infrastructure provisioning.