{"id":1734,"date":"2026-02-20T00:43:44","date_gmt":"2026-02-20T00:43:44","guid":{"rendered":"https:\/\/devsecopsschool.com\/blog\/something-you-have\/"},"modified":"2026-02-20T00:43:44","modified_gmt":"2026-02-20T00:43:44","slug":"something-you-have","status":"publish","type":"post","link":"https:\/\/devsecopsschool.com\/blog\/something-you-have\/","title":{"rendered":"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition (30\u201360 words)<\/h2>\n\n\n\n<p>Something You Have is an authentication\/authorization factor based on possession of a physical or digital object, such as a security key, smartcard, or token. Analogy: a physical key opens a lock; possession proves identity. Formal: a possession-based credential used in multi-factor authentication and authorization workflows.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is Something You Have?<\/h2>\n\n\n\n<p>Something You Have describes a class of security factors and artifacts where access is granted because a user or system physically or logically possesses a specific object or secret. It is NOT knowledge (passwords) or inherence (biometrics), though it is often combined with them.<\/p>\n\n\n\n<p>Key properties and constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Possession-based: must be in control of entity.<\/li>\n<li>Revocable: can be revoked or invalidated centrally.<\/li>\n<li>Transferable risk: loss or theft equals compromise risk.<\/li>\n<li>Tied to lifecycle management: issuance, rotation, revocation.<\/li>\n<li>Usability tradeoffs: physical keys add friction; digital tokens require secure storage.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access to consoles, administrative operations, CI\/CD secrets, API clients.<\/li>\n<li>Service-to-service authentication in zero trust architectures.<\/li>\n<li>Hardware-backed keys for developer laptops, build systems, and privileged sessions.<\/li>\n<li>Integration with cloud identity providers and short-lived credentials.<\/li>\n<\/ul>\n\n\n\n<p>Diagram description (text-only):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>User or service holds a key object; they present it to an authentication gateway; the gateway validates possession and returns a short-lived token; token is used to access cloud resources or sign requests; logging and telemetry record the transaction for observability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Something You Have in one sentence<\/h3>\n\n\n\n<p>A possession-based credential\u2014physical or digital\u2014used to prove identity or authorize actions, often backed by hardware or secure storage and integrated into multi-factor and zero trust flows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Something You Have vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from Something You Have<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Something You Know<\/td>\n<td>Knowledge-based, like passwords or PINs<\/td>\n<td>People mix passwords with tokens<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Something You Are<\/td>\n<td>Biometric identity, like fingerprints<\/td>\n<td>Biometrics are inherence, not possession<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>MFA<\/td>\n<td>Multi-factor is a combination<\/td>\n<td>MFA can include possession as one factor<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>PKI certificate<\/td>\n<td>Certificate is a credential, may be possession-backed<\/td>\n<td>Certificates can be stored or stolen<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>OTP<\/td>\n<td>One-time password is generated or delivered<\/td>\n<td>OTP may be possession or knowledge-based<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>Hardware Security Module<\/td>\n<td>HSM is a secure signing device, a type of possession<\/td>\n<td>HSMs are often shared or cloud-managed<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>Software token<\/td>\n<td>App-stored secret vs hardware token<\/td>\n<td>Software tokens can be cloned<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>FIDO2\/WebAuthn<\/td>\n<td>Protocol using public-key credentials stored on devices<\/td>\n<td>FIDO2 mandates attestation and non-extractable keys<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>Smartcard<\/td>\n<td>Physical card with secure element<\/td>\n<td>Smartcards require reader hardware<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>API key<\/td>\n<td>Static secret used by services<\/td>\n<td>API keys are possession-like but often long-lived<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>T3: MFA explanation \u2014 MFA requires two or more factor types; Something You Have is one factor that improves security when combined with others.<\/li>\n<li>T4: Certificates \u2014 Certificates bind keys to identity; private key possession makes it a Something You Have.<\/li>\n<li>T6: HSM \u2014 HSMs protect keys against extraction and provide signing; managed HSMs are used in cloud.<\/li>\n<li>T8: FIDO2 \u2014 Uses asymmetric keys where private keys are non-exportable and device-bound.<\/li>\n<li>T10: API key \u2014 API keys act as possession factors but are often mismanaged and not rotated.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does Something You Have matter?<\/h2>\n\n\n\n<p>Business impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Revenue protection: prevents account takeovers that lead to fraud or revenue loss.<\/li>\n<li>Trust and compliance: helps meet regulations requiring multi-factor or hardware-backed keys.<\/li>\n<li>Risk reduction: reduces phishing and credential-stuffing effectiveness.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Incident reduction: fewer authentication-driven incidents when properly deployed.<\/li>\n<li>Velocity tradeoff: initial rollout slows onboarding; long-term reduces security incidents.<\/li>\n<li>Automation: allows services to authenticate without human passwords using short-lived tokens.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs\/SLOs: availability of authentication endpoints and key provisioning services.<\/li>\n<li>Error budgets: authentication failures can consume error budgets and trigger rollbacks.<\/li>\n<li>Toil: manual key rotation and recovery increases toil; automation reduces it.<\/li>\n<li>On-call: incidents include lost keys, revoked certificates, or signing service degradation.<\/li>\n<\/ul>\n\n\n\n<p>What breaks in production \u2014 realistic examples:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Lost hardware keys for a team during an emergency deploy -&gt; blocked operations.<\/li>\n<li>Key provisioning service outage prevents CI pipelines from obtaining short-lived creds.<\/li>\n<li>Compromised build server possesses signing keys and pushes malicious artifacts.<\/li>\n<li>Cloud provider rotates HSM and breaks certificate chains for service-to-service auth.<\/li>\n<li>Misconfigured token TTL leads to wide-scale session expiration during peak load.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is Something You Have used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How Something You Have appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Edge \/ Network<\/td>\n<td>TLS client certs or hardware tokens for admin access<\/td>\n<td>TLS handshakes, cert status<\/td>\n<td>Load balancers, reverse proxies<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Service \/ API<\/td>\n<td>Client certificates or signed JWTs for service auth<\/td>\n<td>Auth logs, token issuance<\/td>\n<td>API gateways, service meshes<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Application<\/td>\n<td>User-held security keys or platform tokens<\/td>\n<td>Login events, MFA logs<\/td>\n<td>Identity providers, SDKs<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Data \/ Database<\/td>\n<td>Encrypted keys and key access logs<\/td>\n<td>KMS access logs, DB auth logs<\/td>\n<td>KMS, database IAM<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>IaaS \/ PaaS<\/td>\n<td>Cloud instance identity or attached keys<\/td>\n<td>Instance metadata access logs<\/td>\n<td>Cloud IAM, instance profiles<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>Kubernetes<\/td>\n<td>K8s service account keys or workload identity<\/td>\n<td>Pod identity logs, kube-audit<\/td>\n<td>K8s IRSA, SPIFFE<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>Serverless<\/td>\n<td>Short-lived tokens or signed requests<\/td>\n<td>Invocation auth traces<\/td>\n<td>Serverless platforms, IAM<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>CI\/CD<\/td>\n<td>Build signing keys and deploy tokens<\/td>\n<td>Build logs, agent auth<\/td>\n<td>CI agents, artifact signers<\/td>\n<\/tr>\n<tr>\n<td>L9<\/td>\n<td>Incident Response<\/td>\n<td>Hardware tokens for privileged ops<\/td>\n<td>Access approvals, audit trails<\/td>\n<td>PAM systems, ORCHESTRATION<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>L2: See that service auth often uses mTLS or JWT signed by possession-held private keys.<\/li>\n<li>L6: Workload identity in K8s often maps cloud IAM roles to pods using token exchange.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use Something You Have?<\/h2>\n\n\n\n<p>When necessary:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High-privilege access (admin consoles, production deploys).<\/li>\n<li>Compliance\/regulatory requirements.<\/li>\n<li>Against phishing-prone user bases.<\/li>\n<\/ul>\n\n\n\n<p>When optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Low-privilege or short-lived developer tasks.<\/li>\n<li>Internal tools with strict network controls.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For every microinteraction if it causes significant friction.<\/li>\n<li>As the sole control without rotation or revocation capabilities.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If human admin + internet-facing access -&gt; require hardware-backed possession.<\/li>\n<li>If machine-to-machine short-lived calls -&gt; use ephemeral tokens via KMS or workload identity.<\/li>\n<li>If offline recovery is required -&gt; ensure backup methods and secure recovery workflows.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Use software tokens and enforce MFA for humans; short-lived API tokens for services.<\/li>\n<li>Intermediate: Introduce hardware keys for privileged users; centralized key management for services.<\/li>\n<li>Advanced: Hardware-backed device attestation, automated rotation, workload identity federation, and HSM-backed signing in CI.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does Something You Have work?<\/h2>\n\n\n\n<p>Components and workflow:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Issuance: generate credential (key, cert, token) and bind to identity.<\/li>\n<li>Storage: secure device, HSM, secure enclave, or protected software store.<\/li>\n<li>Proof: present credential to verifier (signing, challenge-response).<\/li>\n<li>Validation: verifier checks signature, revocation, and attestation.<\/li>\n<li>Authorization: upon validation, issuer grants short-lived access tokens or roles.<\/li>\n<li>Revocation: central service marks credential invalid; verifier enforces.<\/li>\n<\/ul>\n\n\n\n<p>Data flow and lifecycle:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Provisioning: generate and store a key in secure store and record metadata.<\/li>\n<li>Activation: user or service binds key to account.<\/li>\n<li>Use: key signs or authenticates; logs emitted.<\/li>\n<li>Rotation: keys periodically replaced or re-attested.<\/li>\n<li>Revocation\/retirement: keys disabled and removed.<\/li>\n<\/ol>\n\n\n\n<p>Edge cases and failure modes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lost\/compromised keys: need recovery and revocation process.<\/li>\n<li>Clock skew affects time-based tokens.<\/li>\n<li>Key extraction vulnerability in software tokens.<\/li>\n<li>Network partitions prevent validation against revocation lists.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for Something You Have<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Hardware token for human MFA \u2014 use for privileged admin flows.<\/li>\n<li>Device-based attestation with platform keys \u2014 use for managed devices and zero trust.<\/li>\n<li>HSM-backed signing for CI\/CD pipelines \u2014 use for artifact signing and certificate issuance.<\/li>\n<li>Workload identity federation \u2014 use for pod-to-cloud IAM with short-lived tokens.<\/li>\n<li>PKI with private keys on smartcards \u2014 use for high-assurance client auth.<\/li>\n<li>Software-based token in secret store with rotation \u2014 use for non-critical service auth.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Lost key<\/td>\n<td>User cannot authenticate<\/td>\n<td>Physical loss or theft<\/td>\n<td>Revoke and re-issue backup key<\/td>\n<td>Auth failure spike<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>Key compromise<\/td>\n<td>Unauthorized access<\/td>\n<td>Stolen or copied key<\/td>\n<td>Rotate keys and audit sessions<\/td>\n<td>Unexpected auth success<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Provisioning outage<\/td>\n<td>New devices fail setup<\/td>\n<td>KMS or CA down<\/td>\n<td>Failover CA or queue requests<\/td>\n<td>Provisioning error rate<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Clock skew<\/td>\n<td>TOTP fail<\/td>\n<td>Device time incorrect<\/td>\n<td>NTP sync and tolerance<\/td>\n<td>TOTP failure metric<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Revocation lag<\/td>\n<td>Revoked keys still work<\/td>\n<td>Caching of validation lists<\/td>\n<td>Shorter cache TTLs<\/td>\n<td>Revocation mismatch logs<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>Extraction from software<\/td>\n<td>Keys exfiltrated from agent<\/td>\n<td>Vulnerable storage<\/td>\n<td>Use hardware-backed stores<\/td>\n<td>Unexpected key usage<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>HSM quota<\/td>\n<td>Signing delayed<\/td>\n<td>HSM throughput limits<\/td>\n<td>Increase capacity or queue signing<\/td>\n<td>HSM latency metrics<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>F2: Rotate keys quickly, search logs for suspicious activity, and revoke affected tokens.<\/li>\n<li>F5: Implement OCSP\/CRL best practices and ensure caches refresh on revocation events.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for Something You Have<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access token \u2014 short-lived credential used after successful authentication \u2014 important for least privilege \u2014 pitfall: long TTLs.<\/li>\n<li>Attestation \u2014 proof a device or key is genuine \u2014 matters for device trust \u2014 pitfall: weak attestation policies.<\/li>\n<li>Authentication \u2014 verifying identity \u2014 foundational for security \u2014 pitfall: reliance on single factor.<\/li>\n<li>Authorization \u2014 granting rights after auth \u2014 separates identity from permissions \u2014 pitfall: over-permissive roles.<\/li>\n<li>Backup key \u2014 fallback possession for recovery \u2014 critical for continuity \u2014 pitfall: insecure storage.<\/li>\n<li>BRUTE-FORCE \u2014 attack pattern against tokens \u2014 matters for defense \u2014 pitfall: lack of rate limits.<\/li>\n<li>Certificate Authority (CA) \u2014 issuer of certificates \u2014 core to PKI \u2014 pitfall: single CA compromise.<\/li>\n<li>Challenge-response \u2014 interactive proof of possession \u2014 protects against replay \u2014 pitfall: predictable challenges.<\/li>\n<li>Chip-backed key \u2014 hardware stored private key \u2014 increases security \u2014 pitfall: device loss.<\/li>\n<li>Clock skew \u2014 time mismatch affecting time-based tokens \u2014 matters for TOTP \u2014 pitfall: hard TTLs.<\/li>\n<li>Client certificate \u2014 TLS cert used by clients \u2014 enables mutual TLS \u2014 pitfall: expired certs.<\/li>\n<li>Cross-signing \u2014 CA signs another CA \u2014 relevant for trust chains \u2014 pitfall: mis-issued certs.<\/li>\n<li>Device fingerprinting \u2014 device attribute profile \u2014 helps detect anomalies \u2014 pitfall: false positives.<\/li>\n<li>Device identity \u2014 unique device identifier \u2014 used in zero trust \u2014 pitfall: spoofable IDs.<\/li>\n<li>Device recovery \u2014 process to regain access \u2014 operational necessity \u2014 pitfall: insecure recovery flow.<\/li>\n<li>Diffie-Hellman \u2014 key agreement protocol \u2014 used in secure channels \u2014 pitfall: weak parameters.<\/li>\n<li>Entropy source \u2014 randomness for key generation \u2014 crucial for crypto \u2014 pitfall: low entropy environments.<\/li>\n<li>Ephemeral credentials \u2014 short-lived tokens \u2014 reduces blast radius \u2014 pitfall: renew failures.<\/li>\n<li>Exportability \u2014 whether private key can be extracted \u2014 hardware keys are non-exportable \u2014 pitfall: exportable keys leaked.<\/li>\n<li>FIDO2 \u2014 modern web auth standard \u2014 provides phishing-resistant keys \u2014 pitfall: poor deployment.<\/li>\n<li>HSM \u2014 hardware security module \u2014 secures keys \u2014 pitfall: misconfiguration.<\/li>\n<li>Identity provider \u2014 issues identity assertions \u2014 central to SSO \u2014 pitfall: single point of failure.<\/li>\n<li>JSON Web Token \u2014 signed token format \u2014 common for services \u2014 pitfall: none validation of alg.<\/li>\n<li>Key rotation \u2014 replacing keys regularly \u2014 reduces long-term risk \u2014 pitfall: missing dependencies.<\/li>\n<li>Key management system \u2014 issues and stores keys \u2014 central to lifecycle \u2014 pitfall: access sprawl.<\/li>\n<li>Key wrapping \u2014 encrypting keys for storage \u2014 used for protection \u2014 pitfall: weak wrapping keys.<\/li>\n<li>KMS \u2014 cloud key management service \u2014 provides managed key lifecycle \u2014 pitfall: permissions misuse.<\/li>\n<li>MFA \u2014 multiple authentication factors \u2014 increases security \u2014 pitfall: poor UX causing bypass.<\/li>\n<li>OTP \u2014 one-time password \u2014 time or event based \u2014 pitfall: interception or SIM swap.<\/li>\n<li>Out-of-band \u2014 separate channel for verification \u2014 helps prevent phishing \u2014 pitfall: slower UX.<\/li>\n<li>PKI \u2014 public key infrastructure \u2014 underpins certificates \u2014 pitfall: expired roots.<\/li>\n<li>Private key \u2014 secret half of asymmetric pair \u2014 possession object \u2014 pitfall: leakage.<\/li>\n<li>Public key \u2014 verifiable half of pair \u2014 verifies signatures \u2014 pitfall: trust mis-assignments.<\/li>\n<li>Revocation \u2014 invalidating credential \u2014 necessary after compromise \u2014 pitfall: stale caches.<\/li>\n<li>Secure enclave \u2014 isolated hardware environment \u2014 protects keys \u2014 pitfall: supply chain risk.<\/li>\n<li>Service account \u2014 non-human identity \u2014 uses possession-based creds \u2014 pitfall: long-lived secrets.<\/li>\n<li>Signature \u2014 cryptographic proof of possession \u2014 used for auth and integrity \u2014 pitfall: weak algorithms.<\/li>\n<li>Smartcard \u2014 card with secure element \u2014 physical possession device \u2014 pitfall: card readers shortage.<\/li>\n<li>Software token \u2014 key stored in software \u2014 convenient but weaker \u2014 pitfall: cloning via malware.<\/li>\n<li>TPM \u2014 trusted platform module \u2014 device crypto root \u2014 important for device attestation \u2014 pitfall: disabled TPM.<\/li>\n<li>Zero trust \u2014 architecture assuming breach \u2014 Something You Have is a device factor \u2014 pitfall: only device checks without risk context.<\/li>\n<\/ul>\n\n\n\n<p>(Note: terms overlap and are intentionally concise; each matters for implementing and operating possession-based security at scale.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure Something You Have (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Auth success rate<\/td>\n<td>Fraction of valid auths<\/td>\n<td>successful auths \/ attempts<\/td>\n<td>99.95%<\/td>\n<td>Include maintenance windows<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Provisioning latency<\/td>\n<td>Time to issue key<\/td>\n<td>time from request to issuance<\/td>\n<td>&lt;30s for automated<\/td>\n<td>Human approvals add delay<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>Key rotation compliance<\/td>\n<td>Percent rotated on schedule<\/td>\n<td>rotated keys \/ scheduled<\/td>\n<td>100% for critical keys<\/td>\n<td>Orphan keys reduce ratio<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Revocation propagation<\/td>\n<td>Time to stop using revoked key<\/td>\n<td>time from revoke to fail<\/td>\n<td>&lt;60s for critical paths<\/td>\n<td>CDN or cache delays<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Unauthorized usage count<\/td>\n<td>Detected suspicious auths<\/td>\n<td>anomalous auth events<\/td>\n<td>0<\/td>\n<td>Requires anomaly detection<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>HSM latency<\/td>\n<td>Signing time<\/td>\n<td>median signing ms<\/td>\n<td>&lt;50ms<\/td>\n<td>Burst queues affect tail<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>MFA enrollment rate<\/td>\n<td>Users registered with possession factor<\/td>\n<td>enrolled users \/ total<\/td>\n<td>95% for admins<\/td>\n<td>Enrollment friction reduces rate<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>Lost key incidents<\/td>\n<td>Incidents due to lost possession<\/td>\n<td>count per period<\/td>\n<td>0<\/td>\n<td>Encourage reporting to reduce impact<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>Token TTL compliance<\/td>\n<td>Fraction using recommended TTLs<\/td>\n<td>compliant tokens \/ total<\/td>\n<td>100% for sensitive<\/td>\n<td>Legacy apps may have long TTLs<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Auth-related toil<\/td>\n<td>Manual ops hours per month<\/td>\n<td>hours logged<\/td>\n<td>Reduce quarter over quarter<\/td>\n<td>Hard to quantify consistently<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>M1: Define valid vs invalid attempts and exclude health checks.<\/li>\n<li>M4: Measure across caches, gateways, and CDN edge to ensure full propagation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure Something You Have<\/h3>\n\n\n\n<p>Pick 5\u201310 tools. For each tool use this exact structure (NOT a table):<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Prometheus + Metrics pipeline<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Something You Have: latency, request rates, auth success\/failure counters.<\/li>\n<li>Best-fit environment: Kubernetes, microservices, on-prem.<\/li>\n<li>Setup outline:<\/li>\n<li>Instrument auth services with counters and histograms.<\/li>\n<li>Export HSM and KMS metrics.<\/li>\n<li>Use pushgateway for short-lived job metrics.<\/li>\n<li>Configure recording rules for SLI computation.<\/li>\n<li>Persist long-term metrics to remote storage.<\/li>\n<li>Strengths:<\/li>\n<li>High resolution metrics and alerting.<\/li>\n<li>Flexible query language for SLIs.<\/li>\n<li>Limitations:<\/li>\n<li>Cardinality issues with many keys.<\/li>\n<li>Requires long-term storage for historical analysis.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 OpenTelemetry + Tracing<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Something You Have: end-to-end auth flows and latencies.<\/li>\n<li>Best-fit environment: Distributed systems, microservices.<\/li>\n<li>Setup outline:<\/li>\n<li>Instrument auth gateways and token issuance paths.<\/li>\n<li>Capture spans for provisioning and validation.<\/li>\n<li>Tag spans with key IDs and revocation status.<\/li>\n<li>Correlate traces with logs and metrics.<\/li>\n<li>Strengths:<\/li>\n<li>Root-cause tracing across services.<\/li>\n<li>Context propagation for audit.<\/li>\n<li>Limitations:<\/li>\n<li>Sampling may miss rare failure modes.<\/li>\n<li>Storage and UX costs for high-volume traces.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Cloud Provider KMS \/ HSM metrics<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Something You Have: usage, latency, errors for key operations.<\/li>\n<li>Best-fit environment: Cloud-managed key operations.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable provider metrics and audit logs.<\/li>\n<li>Monitor quotas and error rates.<\/li>\n<li>Set alerts on latencies and throttling.<\/li>\n<li>Strengths:<\/li>\n<li>Direct visibility into KMS operations.<\/li>\n<li>Integrated IAM logs.<\/li>\n<li>Limitations:<\/li>\n<li>Vendor-specific metric semantics.<\/li>\n<li>Some internals are opaque.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 SIEM \/ Audit log aggregator<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Something You Have: access patterns, anomalous use, revocation events.<\/li>\n<li>Best-fit environment: Enterprise compliance and security.<\/li>\n<li>Setup outline:<\/li>\n<li>Collect auth service logs, KMS logs, and device attestation logs.<\/li>\n<li>Build detection rules for suspicious usage.<\/li>\n<li>Retain logs per compliance requirements.<\/li>\n<li>Strengths:<\/li>\n<li>Centralized investigation and forensics.<\/li>\n<li>Alerting for security incidents.<\/li>\n<li>Limitations:<\/li>\n<li>Alert fatigue without tuning.<\/li>\n<li>High ingestion costs.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 UEM \/ Endpoint management<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Something You Have: device health, attestation, key presence.<\/li>\n<li>Best-fit environment: Corporate devices and managed endpoints.<\/li>\n<li>Setup outline:<\/li>\n<li>Enroll devices and enforce attestation checks.<\/li>\n<li>Report key enrollment and revocation status.<\/li>\n<li>Integrate with identity provider for device posture enforcement.<\/li>\n<li>Strengths:<\/li>\n<li>Control over hardware-backed keys.<\/li>\n<li>Enables device-based policies.<\/li>\n<li>Limitations:<\/li>\n<li>Requires device management buy-in.<\/li>\n<li>Not all devices supported.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for Something You Have<\/h3>\n\n\n\n<p>Executive dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Auth success rate, provisioning backlog, unauthorized usage count, number of enrolled devices, key rotation compliance.<\/li>\n<li>Why: High-level health for executives and risk owners.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Real-time auth failures, provisioning error traces, HSM latency and errors, revocation propagation status, incident queue.<\/li>\n<li>Why: Fast triage and impact assessment for responders.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Per-service auth latency histogram, recent revocations and their propagation, trace links, affected tokens list, user\/device mapping.<\/li>\n<li>Why: Deep troubleshooting and RCA.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What should page vs ticket:<\/li>\n<li>Page: Production auth service down, HSM failure impacting signing, large spike in unauthorized usage.<\/li>\n<li>Ticket: Degraded provisioning latency under threshold, single-user key loss.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>If error budget burn exceeded threshold in short window, escalate and consider rollback of recent auth changes.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Deduplicate alerts by grouping by incident ID or root cause.<\/li>\n<li>Suppress noisy alerts during planned maintenance.<\/li>\n<li>Use alert thresholds with sliding windows and anomaly detection.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Inventory of privileged access points.\n&#8211; Identity provider and IAM model.\n&#8211; Key management solution and HSM or secure enclave availability.\n&#8211; Device management (UEM) strategy for hardware keys.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Define SLIs and events to log (issuance, use, revoke).\n&#8211; Instrument auth flows with metrics and traces.\n&#8211; Ensure audit logs carry key identifiers.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Centralize logs in SIEM or log store.\n&#8211; Export KMS\/HSM metrics to metrics pipeline.\n&#8211; Aggregate device attestation data.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Set auth availability and provisioning latency SLOs.\n&#8211; Create error budgets specifically for authentication outages.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Build executive, on-call, and debug dashboards as described.\n&#8211; Expose per-environment views and filtered access.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Define severity levels and paging rules.\n&#8211; Route auth incidents to both SRE and security teams for mixed-impact events.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for lost key, compromised key, and provisioning outage.\n&#8211; Automate revocation scripts and key rotation where possible.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Load test provisioning and HSM capacity.\n&#8211; Run simulated lost-key drills and game days to validate recovery.\n&#8211; Use chaos engineering to disable KMS or CA and observe system behavior.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Review incidents and SLO breaches monthly.\n&#8211; Expand automation for recurring manual tasks.<\/p>\n\n\n\n<p>Pre-production checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Test key issuance and validation end-to-end.<\/li>\n<li>Ensure revocation propagation works across caches.<\/li>\n<li>Verify monitoring and alerting on metrics.<\/li>\n<li>Confirm backup\/recovery flows for lost keys.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm enrollment coverage for critical users.<\/li>\n<li>Ensure HSM\/KMS capacity meets peak expected load.<\/li>\n<li>Validate automated rotation and revocation policies.<\/li>\n<li>Ensure runbooks are reviewed and accessible.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to Something You Have:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identify affected keys and scope.<\/li>\n<li>Revoke compromised credentials immediately.<\/li>\n<li>Rotate keys and notify stakeholders.<\/li>\n<li>Search audit logs for unauthorized activity.<\/li>\n<li>Restore access via recovery keys and document root cause.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of Something You Have<\/h2>\n\n\n\n<p>1) Privileged admin console access\n&#8211; Context: Admins need secure access to production consoles.\n&#8211; Problem: Password-only access leads to takeovers.\n&#8211; Why it helps: Hardware keys prevent phishing and credential theft.\n&#8211; What to measure: MFA enrollment, auth success rate, lost key incidents.\n&#8211; Typical tools: Hardware tokens, identity provider, UEM.<\/p>\n\n\n\n<p>2) CI\/CD artifact signing\n&#8211; Context: Build artifacts must be verified before release.\n&#8211; Problem: Compromise of build system can introduce malicious artifacts.\n&#8211; Why it helps: HSM-backed signing ensures provenance.\n&#8211; What to measure: Signing latency, unauthorized signing attempts.\n&#8211; Typical tools: HSM, KMS, CI plugin.<\/p>\n\n\n\n<p>3) Service-to-service auth in zero trust\n&#8211; Context: Microservices require secure auth without static secrets.\n&#8211; Problem: Long-lived secrets leak and are hard to rotate.\n&#8211; Why it helps: Workload identity and short-lived tokens bound to instance keys.\n&#8211; What to measure: Token TTL compliance, revocation propagation.\n&#8211; Typical tools: SPIFFE, KMS, service mesh.<\/p>\n\n\n\n<p>4) Remote workforce device authentication\n&#8211; Context: Remote employees use laptops to access resources.\n&#8211; Problem: Device identity is weak; compromised endpoints access sensitive systems.\n&#8211; Why it helps: Device-backed keys enforce posture-based access.\n&#8211; What to measure: Device attestation failures, enrollment rate.\n&#8211; Typical tools: UEM, TPM, identity provider.<\/p>\n\n\n\n<p>5) API consumer authentication\n&#8211; Context: Third-party apps call APIs.\n&#8211; Problem: Static API keys are leaked.\n&#8211; Why it helps: Client certificates or short-lived signed tokens reduce risk.\n&#8211; What to measure: Unauthorized usage, certificate expiry.\n&#8211; Typical tools: API gateway, CA.<\/p>\n\n\n\n<p>6) Smartcard-based government systems\n&#8211; Context: High-assurance logins required.\n&#8211; Problem: Passwords insufficient for sensitive operations.\n&#8211; Why it helps: Smartcards with PIN + card give MFA and non-repudiation.\n&#8211; What to measure: Enrollment, failed auths, revocations.\n&#8211; Typical tools: Smartcards, middleware, PKI.<\/p>\n\n\n\n<p>7) Recovery and emergency access\n&#8211; Context: Keyholders lost devices during incident response.\n&#8211; Problem: Locked-out operators delay recovery.\n&#8211; Why it helps: Backup possession keys and break-glass flows ensure continuity.\n&#8211; What to measure: Recovery time, misuse of emergency keys.\n&#8211; Typical tools: Vault, break-glass protocols.<\/p>\n\n\n\n<p>8) IoT device identity\n&#8211; Context: Thousands of devices talk to cloud APIs.\n&#8211; Problem: Device spoofing and long-lived secrets risk.\n&#8211; Why it helps: Device certificates and hardware roots establish trust.\n&#8211; What to measure: Device attestation success, certificate rotation.\n&#8211; Typical tools: TPM, device registries, fleet management.<\/p>\n\n\n\n<p>9) Database encryption key access\n&#8211; Context: Databases use envelope encryption.\n&#8211; Problem: Exposed DB keys compromise data.\n&#8211; Why it helps: KMS-held keys with access policies bound to instances.\n&#8211; What to measure: KMS access logs, key usage anomalies.\n&#8211; Typical tools: KMS, IAM, DB encryption plugins.<\/p>\n\n\n\n<p>10) Remote signing for financial transactions\n&#8211; Context: High-value transactions require signing.\n&#8211; Problem: Weak signing processes invite fraud.\n&#8211; Why it helps: Hardware-backed signing ensures non-repudiation.\n&#8211; What to measure: Signing latency, unauthorized signing attempts.\n&#8211; Typical tools: HSM, legal signing middleware.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes workload identity with short-lived tokens<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Microservices on Kubernetes need cloud API access without static credentials.<br\/>\n<strong>Goal:<\/strong> Enable secure, short-lived service auth using pod-bound credentials.<br\/>\n<strong>Why Something You Have matters here:<\/strong> Pod identity based on non-exportable keys reduces secret sprawl and limits blast radius.<br\/>\n<strong>Architecture \/ workflow:<\/strong> K8s pod requests a signed token from a workload identity agent which uses a local private key tied to node or pod; agent exchanges proof with cloud STS to receive short-lived credentials.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Deploy workload identity agent as sidecar or node daemon.<\/li>\n<li>Provision device-bound keys into node&#8217;s secure enclave or KMS.<\/li>\n<li>Configure admission controller to inject identity bindings.<\/li>\n<li>Implement token exchange with cloud STS using mutual TLS.<\/li>\n<li>Instrument traces and metrics for token issuance.\n<strong>What to measure:<\/strong> Token issuance latency, token failure rate, unsuccessful auths to cloud APIs.<br\/>\n<strong>Tools to use and why:<\/strong> SPIFFE for identity standardization; KMS for key storage; metrics via Prometheus.<br\/>\n<strong>Common pitfalls:<\/strong> Sidecar injection failures, node-level key compromise, long token TTLs.<br\/>\n<strong>Validation:<\/strong> Game day: disable KMS and observe failover to queued issuance.<br\/>\n<strong>Outcome:<\/strong> Reduced static secret usage and improved auditing of service access.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless function authenticating to third-party API<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Serverless functions call external APIs requiring client credentials.<br\/>\n<strong>Goal:<\/strong> Avoid embedding static API keys in functions and provide revocation control.<br\/>\n<strong>Why Something You Have matters here:<\/strong> Use platform-managed short-lived tokens derived from a signing key to prove possession without embedding secrets.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Function requests platform token from platform KMS\/HSM via secure metadata; platform signs request and returns ephemeral client credential to function.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Store signing keys in KMS with strict IAM roles.<\/li>\n<li>Implement token broker that issues short-lived tokens to functions.<\/li>\n<li>Set conservative TTLs and enforce refresh logic in function code.<\/li>\n<li>Log and monitor token issuance and usage.\n<strong>What to measure:<\/strong> Token TTL compliance, token issuance errors, unauthorized call counts.<br\/>\n<strong>Tools to use and why:<\/strong> Cloud KMS for keys; serverless platform auth metadata; SIEM for logging.<br\/>\n<strong>Common pitfalls:<\/strong> Cold-starts interfering with token refresh, over-permissive roles.<br\/>\n<strong>Validation:<\/strong> Load test high-concurrency token issuance and monitor KMS quotas.<br\/>\n<strong>Outcome:<\/strong> Reduced risk of leaked API keys with centralized revocation.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response: lost hardware keys during outage<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Several on-call engineers lose hardware tokens while responding to outage.<br\/>\n<strong>Goal:<\/strong> Restore access quickly while maintaining security posture.<br\/>\n<strong>Why Something You Have matters here:<\/strong> Lost possession affects human access; processes must allow secure recovery without bypassing controls.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Emergency access flow uses break-glass keys protected in vault with multi-person approval and time-limited access.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Trigger incident playbook that authenticates via alternative factors.<\/li>\n<li>Use break-glass vault to issue temporary admin cred after approvals.<\/li>\n<li>Revoke lost keys and add replacements once validated.<\/li>\n<li>Post-incident, rotate affected keys and audit use of break-glass credentials.\n<strong>What to measure:<\/strong> Time to recovery, break-glass usage count, post-incident revocations.<br\/>\n<strong>Tools to use and why:<\/strong> Vault for emergency creds; ticketing for approvals; logs for audit.<br\/>\n<strong>Common pitfalls:<\/strong> Overused break-glass causing compliance issues, incomplete revocation.<br\/>\n<strong>Validation:<\/strong> Simulated lost-key drill monthly.<br\/>\n<strong>Outcome:<\/strong> Faster recovery with controlled, auditable emergency access.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance: HSM-backed signing at scale<\/h3>\n\n\n\n<p><strong>Context:<\/strong> High-frequency signing in CI pipelines causes HSM costs to spike.<br\/>\n<strong>Goal:<\/strong> Balance security of HSM with cost and throughput needs.<br\/>\n<strong>Why Something You Have matters here:<\/strong> HSM provides non-extractable keys; overuse increases cost.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Hybrid signing: HSM used for root signing and ephemeral keys used for high-volume operations after HSM-approved delegation.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Use HSM to sign and issue short-lived intermediate keys.<\/li>\n<li>Cache intermediate keys with strict TTLs for pipeline use.<\/li>\n<li>Monitor HSM quotas and rotate intermediate keys regularly.<\/li>\n<li>Audit signing operations and restrict scope.\n<strong>What to measure:<\/strong> HSM request rate and cost, signing latency, unauthorized signing attempts.<br\/>\n<strong>Tools to use and why:<\/strong> HSM\/KMS metrics, CI plugin integration, Prometheus for cost telemetry.<br\/>\n<strong>Common pitfalls:<\/strong> Long-lived intermediate keys increasing risk, improper scope delegation.<br\/>\n<strong>Validation:<\/strong> Load test signing flow and measure HSM costs and latency under peak loads.<br\/>\n<strong>Outcome:<\/strong> Lower HSM usage costs while preserving root key security.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: High number of failed MFA attempts -&gt; Root cause: Time sync issues or misconfigured token TTL -&gt; Fix: NTP sync and increase tolerance.<\/li>\n<li>Symptom: Revoked keys still accepted -&gt; Root cause: Cached validation lists -&gt; Fix: Reduce cache TTLs and propagate revocation events.<\/li>\n<li>Symptom: CI builds can&#8217;t sign artifacts -&gt; Root cause: HSM quota exhaustion -&gt; Fix: Increase HSM capacity or queue requests.<\/li>\n<li>Symptom: Excessive alert noise -&gt; Root cause: Unfiltered events from auth service -&gt; Fix: Implement dedupe and severity filters.<\/li>\n<li>Symptom: Lost admin access after device loss -&gt; Root cause: No emergency recovery process -&gt; Fix: Implement break-glass vault and multi-person approvals.<\/li>\n<li>Symptom: Long provisioning delays -&gt; Root cause: Manual approval bottlenecks -&gt; Fix: Automate safe approval flows for low-risk cases.<\/li>\n<li>Symptom: Keys found in code repo -&gt; Root cause: Poor secret handling -&gt; Fix: Secret scanning, revoke keys, and rotate.<\/li>\n<li>Symptom: High tail latency on auth -&gt; Root cause: Synchronous HSM calls in critical path -&gt; Fix: Introduce async signing and caching of short-lived tokens.<\/li>\n<li>Symptom: Unexpected token acceptance -&gt; Root cause: Weak validation of signing algorithm -&gt; Fix: Enforce strict JWT alg checks and key ID mapping.<\/li>\n<li>Symptom: Device attestation failures -&gt; Root cause: Outdated UEM agent -&gt; Fix: Update agents and enforce compatibility.<\/li>\n<li>Symptom: Service account leak -&gt; Root cause: Long-lived service keys -&gt; Fix: Move to workload identity and ephemeral credentials.<\/li>\n<li>Symptom: Poor adoption of hardware keys -&gt; Root cause: UX friction and lack of training -&gt; Fix: Provide enrollment automation and training.<\/li>\n<li>Symptom: Incomplete audit trails -&gt; Root cause: Missing metadata in logs -&gt; Fix: Add key IDs and context to logs.<\/li>\n<li>Symptom: Token replay attacks -&gt; Root cause: Lack of nonce or replay protection -&gt; Fix: Implement nonces and short TTLs.<\/li>\n<li>Symptom: High manual toil for rotation -&gt; Root cause: No automation -&gt; Fix: Implement key lifecycle automation in KMS.<\/li>\n<li>Symptom: False positive device bans -&gt; Root cause: over-aggressive device posture rules -&gt; Fix: Tune risk thresholds and fallback flows.<\/li>\n<li>Symptom: Failure during cloud provider rotation -&gt; Root cause: Assumed availability of old keys -&gt; Fix: Use overlapping validity during rotation.<\/li>\n<li>Symptom: Auditors flag weak MFA -&gt; Root cause: Accepting SMS OTP -&gt; Fix: Move to hardware-backed or app-based OTP.<\/li>\n<li>Symptom: Secret scanning alerts missed -&gt; Root cause: Lack of CI checks -&gt; Fix: Add pre-commit and pipeline scanning.<\/li>\n<li>Symptom: Observability blind spots -&gt; Root cause: Not instrumenting token broker -&gt; Fix: Add metrics, traces, and logs.<\/li>\n<li>Symptom: Overpermissioned keys -&gt; Root cause: Broad role bindings -&gt; Fix: Apply least privilege and scoped keys.<\/li>\n<li>Symptom: Slow incident response -&gt; Root cause: No joint SRE-security playbook -&gt; Fix: Create integrated runbooks and drills.<\/li>\n<li>Symptom: Unauthorized device enrollment -&gt; Root cause: Weak enrollment policy -&gt; Fix: Add attestation and approval gating.<\/li>\n<li>Symptom: TLS client cert expiry -&gt; Root cause: Missing renewal automation -&gt; Fix: Automate cert rotation and alerts.<\/li>\n<li>Symptom: Key export from device -&gt; Root cause: Use of exportable keys -&gt; Fix: Use hardware non-exportable keys and enforce via attestation.<\/li>\n<\/ol>\n\n\n\n<p>Observability pitfalls included above: missing metadata, blind spots, noisy alerts, sampling gaps, and lack of long-term retention.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ownership and on-call: IAM or security team owns key management; SRE owns availability. Joint on-call for auth outages.<\/li>\n<li>Runbooks vs playbooks: Runbooks for operational steps; playbooks for cross-team incident coordination.<\/li>\n<li>Safe deployments: Canary issuance of new CA or key rotation with overlap and feature flags.<\/li>\n<li>Toil reduction and automation: Automate rotation, provisioning, and recovery; use policy-as-code.<\/li>\n<li>Security basics: Least privilege, strict logging, non-exportable keys, attestation, and rapid revocation workflows.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review failed auth spikes, review recent revocations, verify SLI compliance.<\/li>\n<li>Monthly: Rotate non-critical keys, review device enrollment and posture, audit service account usage.<\/li>\n<\/ul>\n\n\n\n<p>Postmortem review items related to Something You Have:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>How was possession verified and did it fail?<\/li>\n<li>Was revocation timely and effective?<\/li>\n<li>Did backups and recovery function as expected?<\/li>\n<li>Were there gaps in observability or instrumentation?<\/li>\n<li>Recommendations for automation and policy changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for Something You Have (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>KMS \/ HSM<\/td>\n<td>Stores and signs with keys<\/td>\n<td>IAM, CI\/CD, K8s<\/td>\n<td>See details below: I1<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Identity Provider<\/td>\n<td>User and device auth<\/td>\n<td>MFA, UEM, SSO<\/td>\n<td>Supports hardware token policies<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Service Mesh<\/td>\n<td>mTLS for services<\/td>\n<td>K8s, SPIFFE, KMS<\/td>\n<td>Terminate mutual TLS inside mesh<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>UEM<\/td>\n<td>Device enrollment and posture<\/td>\n<td>Identity, TPM, Attestation<\/td>\n<td>Enforces device-based policies<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>CI\/CD<\/td>\n<td>Pipeline signing and auth<\/td>\n<td>KMS, HSM, Artifact repo<\/td>\n<td>Integrate secret-less build flows<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>SIEM<\/td>\n<td>Log aggregation and detection<\/td>\n<td>Auth services, KMS, HSM<\/td>\n<td>Centralized security alerts<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Vault \/ Secret Store<\/td>\n<td>Dynamic secrets and break-glass<\/td>\n<td>IAM, Audit logs<\/td>\n<td>Use for emergency creds<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>API Gateway<\/td>\n<td>Client cert and token validation<\/td>\n<td>CA, SIEM, Metrics<\/td>\n<td>Enforce token policies at edge<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>PKI \/ CA<\/td>\n<td>Issue certs for clients<\/td>\n<td>K8s, API gateways<\/td>\n<td>Root CA management needed<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Monitoring<\/td>\n<td>Metrics and alerting<\/td>\n<td>Auth services, HSM<\/td>\n<td>Critical for SLOs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>I1: KMS\/HSM \u2014 Use HSM for root key protection and KMS for managed lifecycle; integrate with CI to sign artifacts and with K8s for pod identity.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What exactly counts as Something You Have?<\/h3>\n\n\n\n<p>Usually a physical token, smartcard, hardware key, or device-protected private key; any credential bound to possession.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can software tokens be considered Something You Have?<\/h3>\n\n\n\n<p>Yes, but software tokens are weaker because they can be copied; hardware-backed keys are stronger.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is SMS OTP acceptable as possession?<\/h3>\n\n\n\n<p>SMS is considered weak and subject to SIM swap; not recommended for high-risk use cases.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How should keys be rotated in production?<\/h3>\n\n\n\n<p>Automate rotation with overlapping validity and validate consumers before retiring old keys.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What happens when a user loses their hardware key?<\/h3>\n\n\n\n<p>Follow recovery runbook: revoke lost key, issue emergency access with approval, then provision replacement.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you detect compromised keys?<\/h3>\n\n\n\n<p>Monitor for anomalous usage patterns, geographic anomalies, and unexpected service calls; correlate with SIEM.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What telemetry is essential?<\/h3>\n\n\n\n<p>Auth success\/failure, provisioning times, revocation events, HSM metrics, and device attestation logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Are hardware keys required for all employees?<\/h3>\n\n\n\n<p>Depends on risk profile; require for privileged users and offer for others based on threat model.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How does Something You Have fit into zero trust?<\/h3>\n\n\n\n<p>It becomes a device factor and a source of attestation used along with risk signals for access decisions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How long should tokens live?<\/h3>\n\n\n\n<p>Short-lived; typical starting points: minutes to hours for high-privilege, hours for services; vary by use case.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can HSMs be a single point of failure?<\/h3>\n\n\n\n<p>Yes; design redundancy and failover and use caching with caution.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you avoid losing access during CA rotation?<\/h3>\n\n\n\n<p>Use overlapping cert validity, staged rollout, and test in lower environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you secure software tokens on developer machines?<\/h3>\n\n\n\n<p>Use secure enclave, disk encryption, and UEM policies; avoid storing secrets in cleartext.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should service accounts use hardware-backed keys?<\/h3>\n\n\n\n<p>Prefer workload identity and ephemeral tokens; hardware-backed keys for highly sensitive services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to handle provisioning at scale?<\/h3>\n\n\n\n<p>Automate enrollment, use attestation, and integrate with device management and identity provider.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What audits are necessary?<\/h3>\n\n\n\n<p>Record issuance, use, revocation, and recovery actions and retain per compliance requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can possession-based factors be phished?<\/h3>\n\n\n\n<p>Hardware-backed attestation and FIDO2 significantly reduce phishing risk; software tokens can be phished.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to escalate when auth systems fail?<\/h3>\n\n\n\n<p>Page SRE and security; use break-glass runbooks and communicate to stakeholders.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Something You Have is a foundational possession-based factor crucial for secure authentication and authorization in modern cloud-native systems. Proper lifecycle management, observability, and automation turn a possession factor from a risk into a strong control.<\/p>\n\n\n\n<p>Next 7 days plan:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory all high-privilege access points and current possession factors.<\/li>\n<li>Day 2: Ensure logging of issuance, usage, and revocation events is enabled.<\/li>\n<li>Day 3: Prototype short-lived token issuance for one non-critical service.<\/li>\n<li>Day 4: Enroll a pilot group with hardware keys and document UX problems.<\/li>\n<li>Day 5: Run tabletop for lost-key incident and refine recovery runbook.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 Something You Have Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>Something You Have<\/li>\n<li>possession-based authentication<\/li>\n<li>hardware security key<\/li>\n<li>hardware-backed key<\/li>\n<li>\n<p>device attestation<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>HSM-backed signing<\/li>\n<li>key management lifecycle<\/li>\n<li>workload identity federation<\/li>\n<li>short-lived tokens<\/li>\n<li>\n<p>device-based MFA<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>What is something you have in authentication<\/li>\n<li>How do hardware security keys work for MFA<\/li>\n<li>How to manage lost hardware tokens in production<\/li>\n<li>How to implement key rotation with HSM<\/li>\n<li>\n<p>Best practices for device attestation in zero trust<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>PKI<\/li>\n<li>FIDO2<\/li>\n<li>WebAuthn<\/li>\n<li>TPM<\/li>\n<li>secure enclave<\/li>\n<li>KMS<\/li>\n<li>mutual TLS<\/li>\n<li>SPIFFE<\/li>\n<li>OCSP<\/li>\n<li>CRL<\/li>\n<li>certificate authority<\/li>\n<li>key wrapping<\/li>\n<li>token exchange<\/li>\n<li>service account<\/li>\n<li>ephemeral credentials<\/li>\n<li>break-glass<\/li>\n<li>UEM<\/li>\n<li>device posture<\/li>\n<li>SIEM<\/li>\n<li>OpenTelemetry<\/li>\n<li>Prometheus<\/li>\n<li>SLO<\/li>\n<li>SLI<\/li>\n<li>error budget<\/li>\n<li>CI\/CD signing<\/li>\n<li>artifact provenance<\/li>\n<li>enrollment<\/li>\n<li>revocation<\/li>\n<li>rotation<\/li>\n<li>attestation<\/li>\n<li>non-exportable keys<\/li>\n<li>exportable keys<\/li>\n<li>smartcard<\/li>\n<li>software token<\/li>\n<li>OTP<\/li>\n<li>PIN<\/li>\n<li>TPM-backed key<\/li>\n<li>hardware token enrollment<\/li>\n<li>emergency access<\/li>\n<li>secure boot<\/li>\n<li>supply chain security<\/li>\n<li>time-based OTP<\/li>\n<li>challenge-response<\/li>\n<li>zero trust device identity<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1734","post","type-post","status-publish","format-standard","hentry"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - DevSecOps School<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - DevSecOps School\" \/>\n<meta property=\"og:description\" content=\"---\" \/>\n<meta property=\"og:url\" content=\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\" \/>\n<meta property=\"og:site_name\" content=\"DevSecOps School\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-20T00:43:44+00:00\" \/>\n<meta name=\"author\" content=\"rajeshkumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"rajeshkumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"28 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#article\",\"isPartOf\":{\"@id\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\"},\"author\":{\"name\":\"rajeshkumar\",\"@id\":\"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b\"},\"headline\":\"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)\",\"datePublished\":\"2026-02-20T00:43:44+00:00\",\"mainEntityOfPage\":{\"@id\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\"},\"wordCount\":5637,\"commentCount\":0,\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\",\"url\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\",\"name\":\"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - DevSecOps School\",\"isPartOf\":{\"@id\":\"https:\/\/devsecopsschool.com\/blog\/#website\"},\"datePublished\":\"2026-02-20T00:43:44+00:00\",\"author\":{\"@id\":\"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b\"},\"breadcrumb\":{\"@id\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#breadcrumb\"},\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/devsecopsschool.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/devsecopsschool.com\/blog\/#website\",\"url\":\"https:\/\/devsecopsschool.com\/blog\/\",\"name\":\"DevSecOps School\",\"description\":\"DevSecOps Redefined\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/devsecopsschool.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b\",\"name\":\"rajeshkumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en\",\"@id\":\"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"caption\":\"rajeshkumar\"},\"url\":\"https:\/\/devsecopsschool.com\/blog\/author\/rajeshkumar\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - DevSecOps School","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/","og_locale":"en_US","og_type":"article","og_title":"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - DevSecOps School","og_description":"---","og_url":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/","og_site_name":"DevSecOps School","article_published_time":"2026-02-20T00:43:44+00:00","author":"rajeshkumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"rajeshkumar","Est. reading time":"28 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#article","isPartOf":{"@id":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/"},"author":{"name":"rajeshkumar","@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b"},"headline":"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)","datePublished":"2026-02-20T00:43:44+00:00","mainEntityOfPage":{"@id":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/"},"wordCount":5637,"commentCount":0,"inLanguage":"en","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["http:\/\/devsecopsschool.com\/blog\/something-you-have\/#respond"]}]},{"@type":"WebPage","@id":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/","url":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/","name":"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - DevSecOps School","isPartOf":{"@id":"https:\/\/devsecopsschool.com\/blog\/#website"},"datePublished":"2026-02-20T00:43:44+00:00","author":{"@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b"},"breadcrumb":{"@id":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#breadcrumb"},"inLanguage":"en","potentialAction":[{"@type":"ReadAction","target":["http:\/\/devsecopsschool.com\/blog\/something-you-have\/"]}]},{"@type":"BreadcrumbList","@id":"http:\/\/devsecopsschool.com\/blog\/something-you-have\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/devsecopsschool.com\/blog\/"},{"@type":"ListItem","position":2,"name":"What is Something You Have? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"}]},{"@type":"WebSite","@id":"https:\/\/devsecopsschool.com\/blog\/#website","url":"https:\/\/devsecopsschool.com\/blog\/","name":"DevSecOps School","description":"DevSecOps Redefined","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/devsecopsschool.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en"},{"@type":"Person","@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b","name":"rajeshkumar","image":{"@type":"ImageObject","inLanguage":"en","@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","caption":"rajeshkumar"},"url":"https:\/\/devsecopsschool.com\/blog\/author\/rajeshkumar\/"}]}},"_links":{"self":[{"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=1734"}],"version-history":[{"count":0,"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1734\/revisions"}],"wp:attachment":[{"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=1734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=1734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=1734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}