Privacy Policy

IDFire is unusual among consumer apps in one respect that shapes this entire document: the product's purpose is to establish that you are a specific real person. We have written this policy to be specific about what that involves rather than to describe it in general terms.

Effective: 24 September 2026  ·  Last updated: 24 September 2026  ·  Version: 1.0

1. Introduction

IDFire Technologies Inc. ("IDFire", "we", "us") provides an identity verification and personal identity management service. This policy explains what personal information we collect, why, how long we keep it, who we share it with, and the choices and rights you have.

Because our purpose is to establish that you are a specific real person, we process categories of information most apps never touch: facial geometry, government identity documents, and hardware attestation. Those categories carry specific legal obligations, and this policy addresses them directly.

This policy covers the IDFire mobile applications for iOS and Android, the IDFire browser extension, idfire.ai and its subdomains, and the IDFire APIs.

It does not cover relying parties — third-party websites and applications that use IDFire to verify their users. When you use IDFire to sign in to another service, that service is an independent controller of whatever it receives from us, under its own privacy policy.

1.1 Who the controller is

IDFire Technologies Inc., a Delaware corporation, is the controller of the personal information described in this policy, except where we act as a processor on behalf of an enterprise customer (Section 13).

• Privacy enquiries and rights requests: privacy@idfire.ai
• General contact: info@idfire.ai
• Data Protection Officer: not yet appointed. We are appointing one, and until we do, privacy enquiries that would go to a DPO should go to privacy@idfire.ai, which is monitored.

2. Information we collect

We group information by how we obtain it. Every row below corresponds to a data flow that exists in the product. We have not listed categories we do not actually collect.

2.1 Information you give us

We do not collect voice biometrics. IDFire has permanently retired voice as a biometric modality. Voice is neither collected, compared nor enrolled on any path. If you previously enrolled voice with IDFire, that data has been scheduled for destruction under our decommissioning process.

2.2 Information collected automatically

2.3 Categories of sources — information from third parties

2.4 What we do not collect

We state these explicitly because their absence is a design decision, not an omission.

• We do not track you across other companies' apps and websites. We do not use advertising identifiers and we do not embed third-party advertising SDKs.
• We do not sell personal information, and we do not share it for cross-context behavioural advertising, as those terms are defined under California law.
• We do not embed third-party analytics or crash-reporting SDKs in the iOS application.
• We cannot read your vault. Vault passwords and attachments are encrypted on your device with keys we do not hold. We receive and store ciphertext only.
• We do not collect a child's precise date of birth. A parent supplies a coarse age band instead.
• We do not collect the content of a child's communications. Child safety monitoring reports event metadata — a flag, a hashed contact identifier, a count — not the content that triggered it.

2.5 Cookies and similar technologies

The idfire.ai website sets no cookies. It uses no analytics, no tag manager, no advertising pixels, no session storage and no local storage, and it loads no fonts, scripts or stylesheets from any third-party domain. There is no cookie banner because there is nothing to consent to.

We state this as a fact about the site as published, not as an aspiration. If we later introduce any cookie that is not strictly necessary, we will ask for your consent before setting it, as ePrivacy and GDPR require, and we will update this section first.

In the mobile applications we store data on your device — your session tokens, your encrypted vault, and your preferences. That is local device storage required to operate the app, not cross-site tracking, and it is removed when you delete the app or your account.

3. Biometric information

This section, together with our Biometric Data Policy, is our publicly available written policy for the purposes of the Illinois Biometric Information Privacy Act (740 ILCS 14/15(a)) and the equivalent provisions of Texas CUBI and Washington HB 1493.

3.1 What we collect and why

We collect facial biometric identifiers, and no other biometric modality. We use them for exactly three purposes:

1. To verify you are a real, live person and not a photograph, mask, recording or synthetic forgery.
2. To confirm the person presenting the identity document is the person in it — we compare your live capture against the photograph on your ID.
3. To confirm you do not already hold an IDFire identity. IDFire is designed so that one human holds one identity. At enrolment we compare a protected representation of your face against existing enrolments.

We do not use biometrics for advertising, for profiling unrelated to identity, for emotion inference, or to identify you to anyone outside IDFire.

3.2 We obtain your written release before we collect anything

Before any biometric capture takes place, we show you a notice explaining what we are about to collect, why, how long we will keep it, and who it may be disclosed to, and we ask you to sign a written release. The capture cannot proceed until that release is recorded. This is enforced on our servers, not merely in the app: a capture request that arrives without a recorded release is rejected before the submitted data is processed at all.

You can decline. If you do, identity verification through document checks remains available, though features that depend on biometric assurance will not be.

3.3 We store protected mathematical representations, not images

The raw captures — the live image of your face and the depth map of its geometry — are used to derive a protected mathematical representation and are not written to durable storage. They are held in memory only for as long as the single request that carries them, and the memory holding them is overwritten before that request returns, on every path including error paths.

What we retain is a transformed vector. It is a renewable, many-to-one protected biometric reference in the sense of ISO/IEC 24745. No exact inverse of it exists, with or without our key. We assert its irreversibility under the standard threat model in ISO/IEC 30136, in which the transform key remains secret; we do not claim resistance to an attacker who holds both the stored reference and the key.

3.4 How long we keep biometric data

We destroy your biometric identifiers on the earliest of:

1. You withdraw biometric consent or revoke your biometric enrolment;
2. You delete your IDFire account;
3. The purpose for collection is satisfied; or
4. 24 months after your last interaction with IDFire.

The 24-month cap is deliberately shorter than the three years Illinois permits, so that a single retention period satisfies Illinois, Colorado, Texas and California at once.

The clock runs from your last interaction, so an active user's biometric data does not expire while they keep using IDFire. The cap bites on dormant and deleted accounts.

Destruction that you trigger — withdrawing consent, revoking enrolment, or deleting your account — is carried out when you ask. The scheduled 24-month sweep is deployed in report-only mode while we complete its safety validation, so records reaching the cap are identified automatically and destroyed under operator control. This is set out in full in our Biometric Data Policy.

3.5 Bans and the one-person-one-identity rule

If an account is banned, a record is kept so that the same person cannot simply enrol again. How that record is kept depends on the seriousness of the conduct.

• For conduct that is actually unlawful — fraud, child sexual abuse material, sanctions evasion, credible threats — and only where there is a documented evidence pack, we may retain a biometric record for the duration of the ban. That retention remains subject to the 24-month cap in Section 3.4. A ban does not create indefinite biometric retention.
• For every other ban — terms-of-service abuse, spam, harassment below the criminal threshold — we keep a non-biometric record only. That record is a keyed hash of your identity document number, date of birth and issuing authority, together with device lineage. A document number is not a biometric identifier, and this record may be retained for longer where a ban justifies it, subject to periodic review and to your right to object under Section 9.

Our ban categories are published in our Terms of Service. No ban category is triggerable by your exercising a right against us — making a data-subject request, complaining to a regulator, or bringing a claim.

3.6 Your biometric choices

• You may decline biometric enrolment, as described in Section 3.2.
• You may withdraw biometric consent at any time in the app. Withdrawal destroys the authentication template and ends biometric sign-in.
• Deleting your account erases your biometric data, subject only to the ban assessment in Section 3.5 and to any legal hold.

3.7 Disclosure

We do not sell, lease, trade or otherwise profit from your biometric information, and we will not disclose it except: with your consent; where required by a valid subpoena, warrant or court order; or to a processor bound by contract to the protections in this policy and prohibited from any other use.

4. Children's information

IDFire supports parent-managed child accounts. This section explains how they work.

4.1 Verifiable parental consent

A child account can only be created by a parent or guardian from their own verified adult IDFire account, and only after verifiable parental consent under COPPA. We record an immutable consent receipt at creation and maintain an append-only ledger of every consent grant, revocation, re-consent and expiry.

4.2 What we collect about a child, and what we deliberately do not

We collect: a display name, a coarse age band rather than a date of birth, the parent-child link, the declared relationship and jurisdiction, a server-issued device identifier, device attestation, and safety-event metadata.

We do not collect from a child: precise date of birth, government identity documents, biometrics, or the content of their communications. A child is routed away from the adult location features entirely; the only child location we collect is an SOS panic location, which a parent enables.

4.3 Child safety monitoring

Where a parent enables it, the app reports safety-event metadata — a screen-capture flag, a hashed contact identifier, event counts. It does not transmit message content, screenshots or browsing history.

Safety events are retained on a category schedule: 90 days for operational events, 180 days for safeguarding, 365 days for contact safety, and two years for exploitation evidence.

Records relating to child sexual abuse material are preserved and reported to the National Center for Missing & Exploited Children as US federal law requires. That preservation overrides deletion requests, including a parent's.

4.4 Parental rights

We comply with the amended COPPA Rule, which took full effect on 22 April 2026. Under it, biometric identifiers are themselves personal information when collected from a child — which is one reason we do not collect biometrics from children at all. We maintain a written children's data retention policy and a written information security programme, as the amended Rule requires, and we do not retain a child's personal information for longer than reasonably necessary for the purpose it was collected for. A parent may consent to our collecting and using a child's information without also consenting to its disclosure to third parties, except where a disclosure is integral to the service itself.

In practice that line falls here. When a child signs in to another service using IDFire, the only things released without a separate parental choice are a pseudonymous identifier and the yes/no assurances the child is signing in to prove — for example "this is a verified, unique person" or "this person is over 13" — together with the minimal header that qualifies those answers. Withholding those would defeat the sign-in the child asked for, so they are integral. Everything beyond that minimum is optional, and a parent can decline it without losing the service. No advertising, analytics or marketing information is disclosed on this path; no such category exists in it.

A parent may review the personal information collected about their child, refuse further collection, and require deletion, at any time, from the parental controls area or by writing to privacy@idfire.ai. Withdrawing consent stops the service for that child account — the account cannot function without it. When consent is revoked, a retention clock starts, and the child's records are erased when it expires, subject only to the preservation obligation in Section 4.3.

5. How we use information, and our legal bases

Where GDPR or UK GDPR applies, we must name a legal basis for each purpose. This table does that. Elsewhere, read the "purpose" column as the operative statement.

Where we rely on legitimate interests, we have assessed that interest against your rights and freedoms, and you may object under Section 9.

5.1 Whether you have to provide this information

GDPR Article 13(2)(e) requires us to tell you whether providing personal information is a statutory or contractual requirement, and what happens if you do not provide it. Plainly:

• Identity details and a government identity document are required to create a verified IDFire identity. It is a contractual requirement, not a statutory one. Without them we cannot verify you, and the service cannot be provided.
• Facial biometrics are not required. They are collected on your consent, which you may refuse or withdraw. If you refuse, document-based verification remains available, and only the features that depend on biometric assurance become unavailable. Refusing does not end your account.
• A phone number is required for verification and for security notifications.
• Location, notifications and the vault are optional. Declining them disables only those features.

6. How we share information

We do not sell your personal information. We share it only as described here.

6.1 Service providers

All hosted personal information is processed in AWS US East (Ohio).

6.2 The one third-party lookup that touches your data

When you ask IDFire to check whether a stored password has appeared in a known breach, we send the first five characters of a hash of that password to Have I Been Pwned, which returns every matching hash suffix for comparison on your device. This is a k-anonymity scheme: the password itself, the full hash, and the account it belongs to never leave your device, and the recipient cannot determine which password was checked.

6.3 Relying parties

When you choose to verify your identity to a third-party service, we disclose only the attributes you approve for that transaction — often a single assertion such as "this person is over 18" rather than your date of birth. You see what will be disclosed before it is.

6.4 Legal and safety disclosures

We may disclose information where required by law, by valid legal process, or to protect the rights, property or safety of IDFire, our users, or the public. Reports of child sexual abuse material are made to NCMEC as federal law requires.

6.5 Business transfers

If IDFire is involved in a merger, acquisition or sale of assets, personal information may transfer. We will give notice before your information becomes subject to a materially different privacy policy. Biometric information will not be transferred except to a successor that assumes the commitments in Section 3, and where separate consent is legally required, we will seek it.

7. How long we keep information

Where a legal hold applies — an active investigation, litigation, or a statutory preservation duty — we retain the affected records until it lifts, even if you have asked for deletion. We will tell you when this is the case, unless we are prohibited from doing so.

8. Automated decision-making

Two IDFire decisions are made automatically and can materially affect you.

1. Enrolment refusal on a uniqueness match. If the one-person-one-identity check concludes that you already hold an IDFire identity, enrolment is refused automatically at the point of detection.
2. Liveness and presentation-attack failure. If the liveness check concludes that a capture is a photograph, mask, recording or synthetic forgery, verification fails automatically.

You have the right to request human review of either decision, to express your point of view, and to contest the outcome. Write to privacy@idfire.ai. A person, not a system, carries out that review, and we maintain an adjudication record of uniqueness reviews.

8.1 The logic involved, and the consequences

GDPR Articles 13(2)(f) and 15(1)(h) entitle you to meaningful information about the logic involved, not merely the fact that a decision was automated. So:

• The uniqueness check. Your face capture is converted into a protected numeric vector. That vector is compared against the vectors of existing enrolments, and the comparison produces a similarity value between 0 and 1. Above a set threshold the system treats the two as the same person. The significance for you is that enrolment is refused and you cannot create the account until the decision is reviewed and overturned.
• The liveness check. The capture and its depth map are assessed for the signatures of a presentation attack — a printed photograph, a screen replay, a mask, or a synthetic forgery. A capture that scores as an attack fails verification. The significance is that verification fails and can be retried.
• What is not used. Neither decision uses your name, age, gender, race, nationality, address, credit history, or any inference about your character or behaviour. They operate on the capture and, for uniqueness, on the gallery of existing enrolments.

Error is possible in both directions, and we do not claim otherwise. Biometric systems have measurable false-match and false-non-match rates. That is precisely why the human review right above exists, and why we test error rates disaggregated across demographic groups rather than reporting a single average.

8.2 Artificial intelligence

The liveness and matching components are machine-learning models. We do not use AI to infer your emotions, your character, your health, or any protected characteristic, and we do not perform biometric categorisation.

Under the EU Artificial Intelligence Act, a system that searches a biometric gallery to identify a person is treated as high-risk, and separate transparency duties apply from 2 August 2026. The IDFire applications are not currently offered in the European Union (see Section 1.1). Before we offer them there we will complete the conformity assessment, technical documentation, logging, human-oversight and accuracy-testing obligations the Act imposes, and we will update this section to say so.

9. Your rights and how to exercise them

Depending on where you live, you have some or all of the following rights.

• Access — obtain a copy of the personal information we hold about you
• Portability — receive it in a portable, machine-readable format
• Correction — have inaccurate information corrected
• Deletion — have your information erased
• Restriction — have processing limited while a dispute is resolved
• Objection — object to processing based on legitimate interests, including the retention of a non-biometric ban record
• Withdraw consent — at any time, without affecting processing already carried out
• Human review — of the automated decisions in Section 8
• Non-discrimination — we will not deny service, charge a different price, or degrade quality because you exercised a right

How to exercise them: in the app under account settings, at idfire.ai/delete-account for deletion, or by writing to privacy@idfire.ai. We respond within the period the applicable law requires — one month under GDPR, 45 days under California law — each extendable where the law permits, in which case we will tell you why.

Verification: because IDFire holds sensitive identity data, we verify a rights request before acting on it. Where you have an account, we authenticate you through it rather than asking you to send further identity documents.

Appeals: if we refuse a request, you may appeal by replying to our decision. Several US state laws require an appeal route; we offer it to everyone.

Authorised agents. You may use an authorised agent to make a request for you. We will ask the agent for written permission signed by you, and we may still ask you to verify your own identity directly or to confirm that you gave the agent permission. Where a request is for a copy of your personal information, we deliver it to you rather than to the agent, because handing an identity file to a third party is itself a risk to you. An agent registered with the California Secretary of State acting under a lawful power of attorney does not need separate written permission.

Opt-out preference signals. We recognise the Global Privacy Control and other browser or device signals that communicate a request to opt out of the sale or sharing of personal information, and we treat such a signal as a valid request from that browser or device. In practice there is nothing for it to stop: we do not sell or share personal information and we do not use it for targeted advertising. We treat these signals as valid regardless, so you do not have to take our word for it.

Do Not Track. There is no common industry standard for responding to browser Do Not Track signals. We do not track you across third-party websites or applications under any circumstances, with or without such a signal.

Complaints: you may lodge a complaint with your supervisory authority. In the EEA that is your national data protection authority; in the UK, the Information Commissioner's Office. In the United States you may complain to your state attorney general, and California residents may complain to the California Privacy Protection Agency.

10. Security

• Post-quantum cryptography. Identity assertions are signed with CRYSTALS-Dilithium5 and key exchange uses CRYSTALS-Kyber1024, so that assertions made today are not retrospectively forgeable by a future quantum computer.
• End-to-end encryption for the vault. Vault contents are encrypted with AES-256-GCM using keys derived on your device. We hold ciphertext only and cannot decrypt it. If you lose your device and your recovery material, we cannot recover your vault — that is the cost of our not holding the keys.
• Hardware-backed keys. Authentication keys are generated in your device's Secure Enclave or equivalent and cannot be extracted.
• Encryption in transit and at rest, access control, audit logging, and least-privilege service permissions.

No system is perfectly secure. We maintain an incident response process and will notify you and the relevant regulators of a qualifying breach within the periods the law requires.

11. Where your data is processed

Personal information is processed in the United States, in AWS US East (Ohio).

If you are in the EEA, the UK or Switzerland and you contact us through our website, that is a transfer outside your jurisdiction. As stated in Section 1.1, the IDFire applications are not currently offered in those markets. Before we offer them there, we will put in place the European Commission's Standard Contractual Clauses, the UK International Data Transfer Addendum, and a transfer impact assessment, and we will say so here.

12. Regional disclosures

12.1 California (CCPA/CPRA)

Categories of personal information collected in the last 12 months: identifiers; personal records under Cal. Civ. Code § 1798.80; characteristics protected under California or federal law (age); commercial information; biometric information; internet and network activity; geolocation; audio and visual information; and inferences.

Sensitive personal information we collect: government identifier; precise geolocation; account log-in credentials; and biometric information processed to uniquely identify you. We use sensitive personal information only for the purposes permitted by § 7027(m) of the CCPA regulations — performing the service, security, and fraud prevention — and not to infer characteristics about you. No right to limit arises from that use, but you may still withdraw biometric consent under Section 3.6.

We have not sold or shared personal information in the preceding 12 months, including the personal information of consumers under 16.

Shine the Light (Cal. Civ. Code § 1798.83). We do not disclose personal information to third parties for those third parties' own direct marketing purposes. There is therefore nothing to request under this section, but you may write to privacy@idfire.ai to confirm it.

California minors (Cal. Bus. & Prof. Code § 22581). If you are a California resident under 18 and registered with IDFire, you may request removal of content you posted publicly. IDFire has no public posting feature, so this right has nothing to operate on; a deletion request under Section 9 is available regardless.

12.2 Illinois (BIPA)

Section 3 and our Biometric Data Policy together constitute our written policy under 740 ILCS 14/15(a), establishing a retention schedule and destruction guidelines. We obtain a written release before collecting or storing a biometric identifier, and we do not sell, lease, trade or profit from biometric identifiers or biometric information.

12.3 Texas (CUBI) and Washington (HB 1493, My Health My Data)

We obtain consent before capturing a biometric identifier for a commercial purpose, we do not sell it, and we destroy it within the statutory period after the purpose expires. The 24-month cap in Section 3.4 satisfies the Texas one-year post-purpose requirement because purpose satisfaction triggers destruction independently of the cap.

12.4 Colorado, Virginia, Connecticut, Utah, Oregon, Montana and other US state laws

Residents of states with comprehensive privacy laws have the rights in Section 9, including the right to appeal a refusal. Where the law requires opt-in consent for sensitive data — which Colorado, Virginia and Connecticut do for biometric and precise geolocation data — we obtain it. We do not process personal data for targeted advertising, and we do not profile with legal or similarly significant effects other than the identity decisions disclosed in Section 8.

Colorado biometric requirements (HB 24-1130, in force 1 July 2025). These apply to any controller processing a Colorado resident's biometric data, whatever its size, so they apply to us. Before collecting a biometric identifier we give notice of the data collected, the purpose, the retention period, and any third-party disclosures; that notice is Section 3 and the Biometric Data Policy, and we obtain consent. We do not sell, lease or trade biometric identifiers, and we do not require biometric consent as a condition of employment.

12.5 Nevada

Nevada residents may submit a verified request that we not sell their covered information under NRS 603A.340. We do not sell covered information, and we have no plans to. Requests may be sent to privacy@idfire.ai.

12.6 Washington consumer health data

Washington's My Health My Data Act defines consumer health data broadly, and its definition of biometric data can reach data generated from the processing of a person's physiological or biological characteristics. We publish a separate Washington Consumer Health Data Privacy Policy, linked distinctly from our homepage, as that Act requires. Nevada's SB 370 provides comparable protections for Nevada residents, and we apply the same practices there.

12.7 EEA and UK

Legal bases are in Section 5. Rights are in Section 9. Processing location is in Section 11. Service availability and our representative position are in Section 1.1.

13. Enterprise and relying-party customers

Where an enterprise customer uses IDFire to verify its own users, that customer is the controller and IDFire is a processor acting on its documented instructions under a data processing agreement. This policy governs IDFire's own controller processing; the customer's policy governs theirs.

14. Changes to this policy

We will post any change here and update the "Last updated" date. For a material change — particularly one affecting biometric processing — we will give advance notice in the app or by email, and where the law requires fresh consent, we will obtain it before the change applies to you. We will not apply a materially different use to previously collected biometric information without your consent.

15. Contact