Is Persona identity verification safe? It can be, for a narrow job. Persona publishes controls for retention, access and deletion. A logo on a security page is not a safety verdict. Your team still owns the configuration, the evidence and the residual risk.
What Safe Means for This Question
Buyers ask one sentence and mean four tests. Safe means the flow collects only what the decision needs. Safe means someone can name who holds the images. Safe means the vendor can show attack-test evidence. Safe means the check matches the risk.
Start with the decision, not the brand. Write the user action in one line. Write the harm if a stranger passes. A newsletter signup and a first payout are not the same harm. The safety bar should move with that harm.
Then separate three ideas that teams often merge. A secure company can still ship an unsafe configuration. A certified capture test can still miss an injection path. A stored ID image can be a liability even when encryption is solid.
Persona is an identity platform. It can verify a government ID, a selfie with liveness, a database record or an NFC chip. Those checks answer who the evidence claims to be. They do not, by themselves, answer whether a live person is present later.
Identity confidence and presence confidence are different signals. Keep that split. A passed ID check is not a standing human signal.
NIST treats identity proofing as a leveled decision, not a single pass. NIST SP 800-63-4 identity assurance levels set different evidence rules for IAL1, IAL2 and IAL3. Biometric comparison is optional at IAL1. Higher levels ask for stronger evidence and a clearer verification path.
Use the level that matches the action. A low-risk signup does not need the same proof as a payout change. Over-collecting documents can raise privacy risk even when the vendor is well run.
Is Persona Identity Verification Safe on Paper?
Persona states that it acts as a processor when it verifies people for a business. The business is the controller. The controller chooses which checks run, who can see the data and how long records stay, within legal limits.
That role split is the first safety fact. A processor can offer tools. The controller still decides the policy. If your privacy notice says images are deleted in days, the vendor setting has to match.
On its security page, Persona says personal data processed for verification is not sold or brokered. It also says that data is not used to train AI or machine learning models. It says deletion methods are available when a request requires them.
Persona also publishes customer-controlled retention, field-level redaction and role-based access. It says transfers are encrypted. It says customers can choose US or EU data residency. It lists alignments that include SOC 2 Type II, ISO 27001 and NIST-related proofing programs. Ask for the current letters. Do not treat a badge list as the report.
Persona’s help center says the business sets how long an ID or selfie is kept. Storage exists so the check, the record or a legal duty can be met. While data is stored, Persona describes encryption and limited access. It says the data is not used for marketing or sale. The business that started the check can see the documents. Other parties should not.
A later Persona privacy note adds a sharper limit on biometrics. It says raw selfies or video and biometric templates can follow different retention rules. It says biometric templates can be configured within a three-year maximum. Deletion from Persona’s systems is described as permanent. Legal holds can still block a delete.
Read those lines as a ceiling, not a promise about your tenant. Three years is a maximum in that note. Your contract can be shorter. If nobody sets a policy, do not assume the shortest one.
Also separate a user’s view from your admin view. The person in the flow can ask for deletion. You can ask Persona to delete what it holds. You still keep whatever your own systems stored. A complete request covers both places.
Persona says verification data is not sold and is not used for marketing. Put the same sentence in the data processing terms. If the contract is silent, the web page is not enough for a regulator or for your own board.
Controls a Buyer Should Confirm
Safety fails in the settings more often than in the slogan. Confirm each control in writing before you turn the flow on.
| Control | What to confirm | Why it matters |
|---|---|---|
| Role | You are controller. Persona is processor. | You own purpose, notice and retention. |
| Collection | Which fields and images the inquiry stores. | Extra images raise breach impact. |
| Retention | Days for selfies, IDs and templates. | A default clock is not your policy. |
| Redaction | Which fields can be wiped and which record stays. | You may need the decision without the image. |
| Access | Which roles can open PII and in which environment. | Broad dashboard access is a safety defect. |
| Residency | US or EU processing for that population. | A global default can break a local promise. |
| Training use | Contract language that bars model training on user data. | A web page is weaker than the DPA. |
| Deletion | API or dashboard path and any legal exception. | A request you cannot execute is not a right. |
Ask for the data processing addendum, not only the marketing page. Map each row to a named owner on your side. Security, privacy and fraud should sign the same record.
Run the table against one real inquiry, not a slide. Create a test user. Complete the flow. Export what was stored. Note the image types, the document number and the timestamp. Then delete or redact and export again. The second export is the proof.
Check environment split the same day. Production and sandbox should not share a long-lived image bucket. A test ID that lives forever is still personal data. Name who can open each environment.
Also ask what a human reviewer can see. Persona says review is off unless you enable it. Enabled review is role-controlled and audited. If you turn review on, name the queue, the region and the log you will keep.
Write the access list as job roles, not as a shared login. Support may need a decision status. Support rarely needs the raw selfie. Fraud may need the image for a short window. Legal should set that window.
Attack Tests Are Not the Same as a Safe Vendor
A safe vendor still has to show how the capture step resists fakes. Presentation attacks and injection attacks are different. A print, a screen or a mask is shown to the camera. An injection attack sends a synthetic stream into the capture path and skips the lens.
ISO/IEC 30107-3 is the test and reporting standard for presentation attack detection at capture. It tells a lab how to test and how to report. It does not certify that every customer deployment is safe. It does not cover injection into the software path.
iBeta is a common lab for that standard. A confirmation letter names a product version, an attack level and a date. Ask for the letter that matches the SDK or API you will ship. An old letter for a different build is not evidence for your integration.
Then ask the injection question in the same review. Who attests the camera frames? Can a modified client submit a video? What happens if the model score and the document score disagree? Write the fail-closed rule before launch.
NIST’s proofing model is the other half. Match the assurance level to the harm. Do not collect a superior document because a vendor flow makes it easy. Document the level you claim and the evidence that supports it.
Ask how the liveness model was tested for people who do not look like the lab set. Lighting, cameras and skin tone change error rates. You want the false-accept and false-reject numbers for the attacks you care about. You do not need a vanity accuracy score.
New figures still need your own sign-off. If a vendor will not share the letter, record the gap. A missing letter is a finding. It is not a reason to invent a number in the business case.
Where a Document Flow Is the Wrong Safety Model
Persona can be a fit when you must bind a government document to a person. Account opening, regulated payouts and some age-restricted products often need that bind. The safety work is then retention, access and test evidence.
It is the wrong model when you only need to know a real person is here, once or again. Storing an ID image to answer that question adds a database you must defend. Many consumer steps do not need a name at all.
VerifEye is built for that second job. VerifEye checks presence, same-person matching and uniqueness. It supports active and passive liveness. Active prompts still help a reviewer, but they are weak against real-time deepfakes. They are not a complete defense.
The face is processed on-device. VerifEye does not retain the biometric after the check. Your platform receives a verification signal, not a stored face. Nothing is kept between sessions unless the application explicitly needs continuity. A match to an enrolled user does not prove account ownership.
Map the check to the journey, not to a single vendor slot.
- Onboard anchors a real, unique person on day zero, without a document when the product does not need one.
- Reverify confirms the same person over time. The face is matched to the enrolled user.
- Protect steps up when risk spikes, such as a payout or a settings change.
- Recover brings a real user back without a weak reset link. Again, a face match is not ownership proof.
Use Persona or any document vendor where the decision needs an identity record. Use VerifEye where the decision needs a human signal with no image left behind. Many programs need both, in sequence, not as substitutes.
For a deeper look at the no-storage model, read how biometric verification works without storage. For the PAD testing lens, use the presentation attack guide for risk teams. The facial verification privacy framework helps when counsel asks what the signal is allowed to retain.
Do not turn this section into a vendor ranking. A document check and a human signal solve different jobs. Calling one unsafe because it stores an ID misses the cases where the law wants that ID. Calling the other incomplete because it skips the ID misses the cases where the ID is the risk.
A Short Review You Can Run This Quarter
Do not boil this down to a yes or no slide. Run a fixed review and keep the packet.
- Name the user action and the harm if a fake person passes.
- Pick the NIST assurance level you will claim. Or state that you are not claiming one.
- List every image and field the inquiry stores.
- Set retention, redaction, residency and access in the tenant. Export the settings.
- Attach the current PAD letter and note what it does not cover, including injection.
- Write the fail-closed rule when document and liveness scores disagree.
- Decide which steps need a human signal with no stored face. Decide which steps need a document.
- Record the owner for deletion requests and the legal exceptions.
- Re-test after any SDK or inquiry change. An old letter does not cover a new build.
If any row is unknown, the honest status is not yet safe for that use. That is a better answer than a vendor score.
Keep the packet short enough to reread. One page for the decision. One page for the settings export. One page for the letters and the gaps. A long binder that nobody opens is not a control.
Review the packet when the product changes, not only on a calendar. A new payout step, a new country or a new reviewer queue can move the harm. The earlier yes does not travel with that change.
Share the result with product and counsel in the same note. Product needs the user step. Counsel needs the retention line. Fraud needs the fail-closed rule. If those three disagree, you do not have a safety decision yet.
The 1 Billion Verifications paper is a useful next read. It covers a human signal that does not keep the image.
Frequently Asked Questions
Is Persona identity verification safe for every signup?
No. It can be appropriate when you need a document or database bind and you configure retention and access. It is a poor fit when you only need a live person and would rather not store an ID image.
Does Persona decide how long my users’ selfies are kept?
Persona says the business sets that clock. Its help content says the retention period follows the business that requested the check. Confirm the number in your tenant and in the contract.
Does a PAD test letter mean the integration is safe?
No. ISO/IEC 30107-3 covers presentation attacks at capture and how results are reported. Ask whether the letter matches your build. Ask separately how injection is stopped.
Does a passed identity check prove a real person is still present?
No. Identity evidence and a live human signal answer different questions. Re-check presence at the moment that matters. Do not treat an old ID pass as ongoing consent.
Can VerifEye replace a government ID check?
Not when the decision legally needs a document. VerifEye confirms presence, same-person matching and uniqueness. It does not store the face. Keep the document vendor where identity proof is required.
Verify real humans. Without the friction.
VerifEye confirms users are real and unique in seconds. No documents, no stored data, no drop-off.