TL;DR: Tenant Inc. used web-based KYC, liveness checks, document capture, and audit trails to support fully remote self-storage rentals while balancing fraud risk, conversion, and emerging compliance pressure, according to Incode. The core lesson is that identity verification must be designed as an operational control, not a checkout feature.
At a glance
What this is: This is an Incode case study showing how Tenant Inc. embedded remote identity verification into a vertical SaaS rental flow to reduce fraud risk and support compliance readiness.
Why it matters: It matters because IAM, KYC, and fraud teams need to treat identity proofing, auditability, and customer friction as a single governance problem when physical onboarding moves online.
By the numbers:
- Tenant Inc. operates in a rapidly growing $350B self-storage sector in the U.S.
👉 Read Incode's case study on Tenant Inc.'s remote identity verification model
Context
Remote onboarding changes the identity problem from a face-to-face trust judgement to a governed verification workflow. In self-storage, the question is not just whether a customer can sign up online, but whether the rental process can prove who is renting, preserve evidence, and support later review when something goes wrong.
That is why KYC in vertical SaaS matters to IAM practitioners. It sits at the intersection of human identity proofing, fraud prevention, audit logging, and policy enforcement, especially when digital channels replace in-person checks and when regulation may tighten after the platform is already live.
Key questions
Q: How should security teams govern remote identity verification in customer onboarding?
A: Treat remote identity verification as a governed control, not a UX feature. Tie document checks, selfie matching, liveness signals, decision outcomes, and audit logs to the same transaction record so later review is possible. The key is to preserve evidence, define exception paths, and keep verification aligned with the risk of the service being offered.
Q: Why do self-service rental workflows need stronger identity proofing than traditional onboarding?
A: Because the platform no longer has a human intermediary making an in-person trust judgement. Remote onboarding removes face-to-face context, so the system must compensate with stronger proofing, traceable evidence, and defined policies for exceptions. Without that, fraud, misuse, and accountability gaps become much easier to exploit.
Q: What breaks when identity verification is treated as a one-time check?
A: The programme loses traceability. A one-time check may stop a bad signup, but it does not preserve enough evidence to explain later misuse, disputes, or compliance questions. Identity controls work best when they connect proofing, authorisation, logging, and retention into one reviewable workflow.
Q: Who is accountable when a digital onboarding flow allows fraud or misuse?
A: Accountability sits with the organisation that designed the proofing path, exception handling, and evidence retention. If those controls are weak, responsibility cannot be outsourced to the customer, the verifier, or the regulator. For regulated workflows, the security team and business owner must share the governance model.
Technical breakdown
Web-based KYC as an identity control layer
Incode's case study describes KYC as an embedded control in the checkout path rather than a separate compliance step. The operational pattern combines document capture, selfie comparison, liveness detection, and form autofill so the platform can confirm identity at the point of rental. That matters because the identity proofing event becomes part of the transaction record, not an afterthought. For SaaS platforms in regulated or semi-regulated workflows, the control objective is to reduce fraud while preserving a traceable decision trail.
Practical implication: Design proofing so the verification event and the transaction record are linked from the start.
Audit trails, reporting, and post-incident traceability
The article emphasises event-level audit trails and reporting because digital rental fraud is rarely resolved at the moment of signup. Auditability gives operators evidence for incident response, dispute handling, and internal review when a rental turns into misuse, abandonment, or theft risk. In IAM terms, this is the difference between a one-time authentication event and a governed identity workflow with retained evidence. For compliance teams, those logs are what make a future mandate or investigation operationally survivable.
Practical implication: Keep verifiable identity events, not just approval outcomes, available for investigation and reporting.
Flexible verification paths for mixed digital maturity
Tenant Inc. also supports optional in-store verification for customers who cannot or will not complete remote proofing. That hybrid design matters because identity controls fail when they assume every user can follow the same path. A mature programme has to preserve security while accommodating different customer capabilities and local operating realities. In practice, this is a policy question as much as a UX question: where the control sits, what exceptions exist, and how those exceptions are recorded.
Practical implication: Define alternate proofing paths up front and govern exceptions with the same discipline as the primary flow.
Threat narrative
Attacker objective: The objective is to obtain a rental or operational foothold under a false or weakly verified identity so the unit can be misused with reduced accountability.
- Entry occurs when a customer begins a remote rental workflow without an in-person identity check.
- Credential or identity evidence is established through document upload, selfie matching, and liveness detection, which determines whether the requester is accepted.
- Impact follows if weak verification allows misuse of storage units, fraud, or later disputes that the platform cannot easily evidence or reconstruct.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
KYC is becoming an identity governance problem, not just a fraud screen. Tenant Inc.'s use case shows that verification, auditability, and customer routing now sit inside the identity control plane for digital services. Once the platform owns the onboarding path, it also owns the trust decision, the exception path, and the evidence trail. Practitioners should treat KYC as part of broader identity governance, not as a detached point solution.
Auditability is the real control outcome here, not biometrics alone. Selfie matching and liveness detection are only useful if the resulting event can be reviewed, defended, and correlated with later incidents. That is the difference between a one-time assertion and a governed identity lifecycle record. The implication is that identity teams need evidence retention and decision traceability as first-class requirements.
Flexible proofing models will define the next phase of customer identity design. Tenant Inc. had to support both online and in-store verification because not every user can complete the same digital path. That makes exception handling part of the control design, not a workaround. The broader lesson for IAM and KYC teams is that a single rigid flow will not survive mixed customer readiness or shifting regulatory expectations.
Identity verification in vertical SaaS now carries compliance pre-positioning value. The article shows a platform trying to stay ready for future state or federal mandates without reworking the customer journey later. That is a strategic governance posture, not merely a product feature. Practitioners should interpret this as a signal that identity architecture is increasingly a forward-compatibility issue, especially in regulated workflows.
PII handling and proofing evidence must be governed together. The more identity evidence a system collects, the more it must control how that data is stored, retained, and used across operations and compliance. When identity proofing becomes part of the transaction record, the organisation inherits privacy obligations along with security obligations. Teams should align identity proofing design with data minimisation and retention policy from the outset.
From our research:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- The NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding reduce the governance gaps that proofing alone cannot close.
What this signals
Identity proofing will keep moving closer to the transaction boundary. As more customer journeys shift online, security teams need to design verification so it survives audit, dispute, and regulatory review, not just sign-up success. That means policies for exception handling, evidence retention, and access to proofing data need to be planned alongside the onboarding flow.
With 30.9% of organisations storing long-term credentials directly in code, according to the Ultimate Guide to NHIs, the same governance discipline that protects machine access also matters when customer identity workflows depend on APIs and back-end automation.
PII-heavy proofing flows create a shared security and privacy workload. Teams should expect tighter scrutiny over retention, minimisation, and access to verification artefacts. The practical test is whether the programme can explain, evidence, and revoke identity decisions long after the customer has left the checkout flow.
For practitioners
- Map identity proofing to the transaction record Ensure the verification event, decision outcome, and rental activity are retained together so disputes and investigations can reconstruct what happened without stitching logs across systems.
- Govern exception paths as policy, not improvisation Define how customers who cannot complete remote proofing are handled, who approves alternative flows, and what evidence is captured when in-store verification is used.
- Separate proofing evidence from raw PII handling Limit who can access documents, selfies, and derived identity attributes, and apply retention rules so proofing data is not kept longer than the operational need.
- Build future-mandate readiness into onboarding design Review whether today’s digital identity workflow could absorb a new state or federal requirement without redesigning customer experience, audit logging, or approval paths.
Key takeaways
- Remote onboarding turns identity verification into a control that must be auditable, not just usable.
- The useful evidence is the verification trail, because later incidents depend on what the platform can prove.
- Hybrid proofing paths and future-mandate readiness belong in the identity design, not as add-ons.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access decisions are central to onboarding control design. |
| NIST SP 800-53 Rev 5 | IA-2 | Authenticated identity proofing and account establishment are directly relevant here. |
| GDPR | Art.32 | Biometric and PII-heavy proofing requires security of processing and access control. |
Limit access to proofing data, protect it in transit and at rest, and document retention rules under Art.32.
Key terms
- Identity Proofing: Identity proofing is the process of establishing that a person is who they claim to be before granting access or completing a transaction. In digital onboarding, it combines document evidence, biometric signals, and policy checks so the organisation can trust the identity assertion well enough to proceed.
- Liveness Detection: Liveness detection is a verification control that checks whether a biometric sample comes from a live person rather than a photo, replay, or synthetic input. It strengthens remote identity proofing, but it only has value when the result is tied to an auditable decision and retained evidence.
- Audit Trail: An audit trail is a record of events that shows what happened, when it happened, and which decision points were involved. For identity workflows, it should capture verification attempts, outcomes, exceptions, and changes so investigators and compliance teams can reconstruct the control path later.
- Exception Handling: Exception handling is the governed process for dealing with cases that do not fit the standard identity workflow. In identity programmes, it defines who can override the normal path, what evidence is required, and how the exception is recorded so security does not depend on improvisation.
What's in the full article
Incode's full article covers the operational detail this post intentionally leaves for the source:
- How Tenant Inc. integrates document capture, selfie match, and liveness detection into the checkout flow.
- What the event-level audit trails and reporting outputs look like for incident handling and compliance review.
- How optional in-store verification is handled when customers cannot complete remote identity proofing.
- Why the platform links proofing data to structured form autofill and reduced manual input.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org