> This is part 1 of 3 of the full documentation (pages 1–100 of 245). > The content is paginated: fetch every part to see all of it. > Next part: https://docs.1kosmos.com/llms-full.txt/1 > Page index: https://docs.1kosmos.com/llms.txt # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.1kosmos.com/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # Home Welcome to your team’s developer platform

1Kosmos Documentation

Welcome to your team’s new developer platform. Everything you need to design, deploy, and scale identity verification and authentication with 1Kosmos.

Explore by Topics

Cover image
Verify a User IdentityCapture and verify user identities using document + selfie + liveness checks.DocsGroup 1109.png
Build Custom WorkflowsDesign verification journeys with no-code Workflow Builder.Workflow BuilderGroup 1120.png
Integrate with your SystemUse APIs and SDKs to connect 1Kosmos with your app.https://documenter.getpostman.com/view/50203634/2sB3dHWZ1n#introGroup 1146.png
Enable AuthenticationConfigure passwordless login and user access flows.Getting started with passwordless authentication
Account ManagementManage your account settings, user profile, permissions and security preferencesGetting Started with AdminX

Explore by Products

#### Identity Verification
OverviewOverview
Verification FlowsVerification flow
Biometric & LivenessBiometric and Liveness
Verification MethodsVerification Methods
Fraud PreventionFraud Prevention
IAL2 VerificationIAL2 Verification
Non-Doc VerificationNon-doc Verification
#### Authentication
Windows Workstation MFAOverview
Passwordless Web ApplicationsPASSWORDLESS FOR WEB APPS
Passwordless for Radius & LDAPAuthentication Broker
Passwordless for Linux SSHPasswordless for Linux SSH
1Kosmos Mobile Application1Kosmos Mobile Application
1Key Biometric1Key Biometric
Orion Desktop AuthenticatorOrion Desktop Authenticator
AdminX (Admin Portal)Admin Portal
#### Integrations
Identity Verification IntegrationsIdentity Verification
Custom IntegrationsCustom Integrations
Desktop Single Sign OnDesktop SSO
Pre-Built Authentication IntegrationsPre-built Integrations
1Kosmos as an External Identity ProviderExternal Identity Provider (SSO Federation)
ServiceNow - Identity Verification for Account ManagementServiceNow - Identity Verification for Account Management
# Privacy policy Digital identity verification and authentication software that verifies users, eliminates passwords, and stops fraud across workforce, customer, and resident identities. ### **1.** **Purpose** At 1Kosmos, data privacy is important to us. This Privacy Policy explains how One Kosmos Inc. and its affiliates (collectively “1Kosmos”, “One Kosmos”, “us” or “we”) collects, uses, discloses, stores, safeguards and retains your Personal Information. Please take the time to read this Privacy Policy carefully in order to understand how we collect, share, and otherwise process information relating to individuals (“Personal Data”). This Privacy Policy describes our practices with respect to the personal information we collect from professionals and other individuals who interact with us directly, such as visitors to [https://www.1kosmos.com](https://www.1kosmos.com/). ### **2.** **Personal Information** “**Personal Information**” means information, other than business contact information, about an identified or identifiable individual. This includes but shall not be limited to name, location data, identification number and such other information. If any of your Personal Information collected or stored by us or our service providers is not accurate, complete or up-to-date, please contact our Chief Privacy Officer so that we can correct the information or direct you to the third party responsible for correcting the information. This Privacy Policy applies to Personal Information that we collect when you use our website or services, and to public Personal Information that we may collect from third party websites. This Privacy Policy does not apply to the practices of companies or other entities that we do not own or control, or to people that we do not employ or manage. Any Personal Information that you supply, or authorize us to supply to any third parties is governed by the privacy policies of those third parties. ### **3.** **Collection** 1Kosmos collects personal information from individuals who interact with us directly through our website, mobile app or at trade shows, or business meetings. We only collect personal information when we have a legal basis for doing so. We collect information from and about you in connection with your use of the Services. Some examples of the types of information that we may collect include: * contact information, such as your name, address, telephone number, email address; * usage information and history, such as your usernames, internet protocol (IP) addresses, support ticket history, and website usage information; * meaningless but unique numbers (MBUN); and * persistent anonymous identifiers (PAI). ### **4.** **Usage** 1Kosmos will not sell, rent, or trade your Personal Data. We will only transfer your Personal Data at your request, and with your consent, for use by third parties to verify your identity or community eligibility, or as required for the prevention of fraud or otherwise permitted by law. We will collect and use your Personal Information in connection with the provision of products and services from our website including: i. delivery of our services, such as our authentication service(s) or our identity service(s) ii. carrying out transactions that you have requested, iii. to fulfill our contractual obligations towards you, iv. for billing purposes, v. in order to communicate with you about new products and services, and promotional offers, and such other marketing purposes vi. to prevent fraud and other prohibited or illegal activities, and vii. managing recruitment and employment relationships; viii. to resolve disputes, enforce our agreements, and as otherwise permitted or required by law. We may use your Personal Information, in conjunction with information available from third parties, to provide the complete functionality of our services. ### **5.** **Disclosure** We may share your Personal Information with our corporate affiliates to carry out transactions that you request or to make our business, or that of our corporate affiliates, more responsive to your needs. We will not sell, trade, or disclose to third parties any Personal Information — including customer names and addresses — without the consent of the customer. We may share your Personal Information with third parties that we engage to provide products and services on our behalf, or to third parties on whose behalf we collect your Personal Information. We will also not disclose your Personal Information to third parties for the purposes of the third-party marketing products to you. We may disclose your Personal Information: * to any governmental authority as part of an investigation to determine our compliance with any applicable law, rule or regulation (including privacy laws, rules and regulations); * in response to a court order, subpoena, discovery request or other lawful judicial or administrative proceeding; * in order to comply with an applicable law, rule or regulation; and * in good faith, to protect or defend our rights or property, or the rights or property of other customers or users. * during negotiations or completion of any business transaction—such as a merger, acquisition, divestiture, sale, or financing of all or part of 1Kosmos. * your request and explicit consent, we will share your personal data with third parties to verify your identity or community eligibility, or otherwise as directed by you. ### **6.** **Accuracy** If any of your Personal Information collected or stored by us or our service providers is not accurate, complete or up-to-date, please contact our Chief Privacy Officer so that we can correct the information or direct you to the third party responsible for correcting the information. ### **7.** **TrueDepth API** Our app makes use of automatically collected information using the device camera and the TrueDepth API provided by Apple. This information is used to track the user’s head and face so that we can detect any kind of image or video spoofing thus making LiveID scan feature more robust. None of the information collected by the TrueDepth API ever leaves the user’s device nor is it persistently stored on the device. ### **8.** **Data retention** Your Personal Information will be retained only as long as necessary for the purposes for which it was collected, or until you request that we delete it, in which case it will be deleted in accordance with (and subject to) our data retention policy and our legal obligations. You should exercise discretion when disclosing your Personal Information to us, and should not disclose sensitive or confidential information that you wish to remain private. Note that retention periods vary in different jurisdictions and are set in accordance with local regulatory and professional retention requirements. ### **9.** **Security posture & measures taken** Security is a critical priority for 1Kosmos. We maintain a comprehensive, written information security program that contains industry-standard administrative, technical, and physical safeguards designed to prevent unauthorized access to Personal Data. We have implemented reasonable technology and security features appropriate to the sensitivity of the information to safeguard the privacy of your Personal Data from unauthorized access or improper use. These measures include, but are not limited to: * Encryption of data in transit and at rest. * Access controls and authentication mechanisms to limit data access to authorized personnel only. * Regular security assessments and vulnerability testing. * Comprehensive written information security program designed to maintain confidentiality, integrity, and availability of Personal Data. However, no security system is perfect, and due to the inherent nature of the Internet, we cannot guarantee that data, including Personal Data, is absolutely safe from intrusion or other unauthorized access by others. You are responsible for protecting your credential(s) and maintaining the security of your devices. If you use the 1Kosmos online service via a subscription purchased for you by a 1Kosmos customer, then that customer is responsible for configuring your instance appropriately. Additional information about security settings and configurations can be found in the documentation related to our online service, including the Trust & Compliance documentation. ### **10.** **Privacy Rights** #### **10.1.** **Your European Privacy Rights** Under the General Data Protection Regulation, if you are a European Union data subject, you have rights to understand and request how we collect, use, and disclose Personal Data in our capacity as a data controller to the extent permitted by applicable law. **Right to Access.** You have the right to access your Personal Data held by us. Please note that we do not have access to, or the ability to share, information about you. For information about fraudulent activities, you may contact the relevant fraud prevention agency for further information. **Right to Rectification.** You have the right to rectify inaccurate Personal Data and, taking into account the purpose of processing, to ensure it is complete. **Right to Erasure (or “Right to be Forgotten”).** You have the right to have your Personal Data erased or deleted, and that is under your complete control. **Right to Restrict Processing.** You have the right to restrict our processing of your Personal Data where applicable. You can ask us to do this if: * you dispute the accuracy of your personal information; * our processing is unlawful but you prefer restriction to deletion; * we no longer need the information but you need it for legal reasons; or * you have objected to our processing and we are still dealing with this objection. If you would like to contact us about your restriction rights, please complete our online [form](https://www.1kosmos.com/contact/). **Right to Data Portability.** You have the right to transfer your digital Personal Data when requested, when possible, through the digital wallet. **Right to Object.** You have the right to object to the processing of your Personal Data that is carried out on the basis of legitimate interests, such as direct marketing. There are unlikely to be any circumstances when this right applies to 1Kosmos Identity Verification service personal information. If you want to contact us about your objection rights, please complete our online [form](https://www.1kosmos.com/contact/). **Right Not to be Subject to Automated Decision-Making.** You have the right not to be subject to automated decision-making, including profiling, which produces legal effects. 1Kosmos does not currently engage in the foregoing on our websites or in our products and services. **Right to Withdraw Consent**: You may withdraw your consent at any time without affecting the lawfulness of processing before withdrawal. **Right to Lodge a Complaint**: You have the right to lodge a complaint with your local data protection authority if you believe your rights have been violated. **Legal Basis Transparency**: We process Personal Data based on consent, contractual necessity, legitimate interests, or other lawful grounds as described in this policy. If you would like to make a request and exercise your rights described above, please complete our online [form](https://www.1kosmos.com/contact/). #### **10.2.** **Your California Privacy Rights** Under the California Consumer Privacy Act of 2018 (“CCPA”), effective January 1, 2020, if you are a California resident, you have rights to understand and request that we disclose how we collect, use, disclose, and sell your Personal Data to the extent permitted by applicable law. If you would like to learn about our verification process, including the details that you must provide to us to verify your request, [click here](https://www.1kosmos.com/contact/). **Right to Know About Personal Data Collected, Disclosed, or Sold.** You have the right to request that we disclose what Personal Data we collect, use, disclose, and sell. **Right to Request Deletion of Personal Data.** You have the right to request the deletion of your Personal Data collected or maintained by us as a business. **Right to Opt-Out of the Sale of Personal Data.** You have the right to opt-out of the sale of your Personal Data by us as a business, in the event we sell Personal Data. **Right to Non-Discrimination for the Exercise of Your Privacy Rights.** You have the right not to receive discriminatory treatment by us for the exercise of your privacy rights conferred by the CCPA. **Right to Limit Use and Disclosure of Sensitive Personal Information.** You have the right, at any time, to direct us to limit the use of your sensitive personal information to what is necessary to perform the services or provide the goods you would reasonably expect when you request those goods or services, in line with applicable law. **Right to Data Portability.** You have the right to receive the specific pieces of personal information we have obtained from you in a format that is easily understandable to the average person and transmit it to another entity. * Where technically feasible, this information shall be provided in a structured, commonly used, machine-readable format. * Additionally, you have the right to request that this information be transmitted to another entity without hindrance if you so choose. #### **10.3.** **Your Indian Privacy Rights** Under Digital Personal Data Protection Act, 2023, if you have any questions or wish to know which personal data we hold about you, please contact us. If it does not conflict with any applicable laws, you are entitled to the following: * Knowledge of why your personal data is needed, what will happen to it, and the duration of its retention. * Copies of your personal data upon request, subject to certain conditions and a possible small fee for this service. * Correction of any information you believe is inaccurate, as well as completion of information you consider incomplete. * Erasure of your personal data under certain conditions. * Objection to our processing of your personal data under certain conditions. * Nomination of any other individual who, in the event of your death or incapacity, be able to exercise these rights. * Grievance redressal against your request. * Notification in the event of a personal data breach, subject to certain conditions. Please make sure to clearly identify yourself when making a request to ensure that we do not modify or delete the data of the wrong person. ### **11.** **International Transfers of Personal Information** 1Kosmos is Delaware Corporation with operations across the globe. If you reside outside the USA, your Personal Data may be processed or stored in the USA or other countries of operation which may not have equivalent privacy or data protection laws. However, regardless of where your personal information is transferred, we will protect it in accordance with this Privacy Policy and applicable laws. Please reach out to us if you require more information about our cross-border transfers. ### **12.** **Authorized Agent** You may designate an authorized agent to make a request under the CCPA on your behalf by us with a copy of your power-of-attorney document granting that right. ### **13.** **Financial Incentives.** We do not provide any financial incentives tied to the collection, sale, or deletion of your Personal Data. If you would like to make a request and exercise your rights described above, please complete our online form, or contact us via the telephone number listed in the contact us page. If you would like to opt-out of Personal Data sharing with marketing and advertising third parties through the use of cookies, please see the section above on Your Privacy Choices. Since there is no reasonable way for us to verify information for which we are a service provider to our customers, we will not respond to any requests in relation to data we hold on behalf of our customers. ### **14.** **Third-Party Websites** Our website and services may include links to third-party websites for your convenience. Accessing and using such linked websites will result in your departure from our site. These third-party websites are subject to their own privacy policies. We advise you to review the privacy notices of each third-party website you visit before submitting any personal data. We do not exercise control over these third-party websites and are not responsible for their content or privacy practices. Should you choose to access any of the third-party websites linked from our site, you do so at your own risk. ### **15.** **Children** Our website is not designed to attract children, and it is not our intent to collect personal data from children under the age of consent in their country of residence. We therefore request that children under the age of consent do not submit any personal data to us. ### **16.** **Withdrawal of consent** You may withdraw your consent to the collection, use and disclosure of your Personal Information at any time. To do this, please contact our Chief Privacy Officer. Withdrawal of your consent to the collection, use and disclosure of your Personal Information will result in you being unable to continue to use our website or services. ### **17.** **Submitting a Complaint** If you are not satisfied with the way in which we handle a complaint about the processing of your personal data, you have the right to submit a complaint to the Data Protection Board of India. ### **18.** **Amendments to this Privacy Statement** We reserve the right to make amendments to this privacy statement. We recommend that you regularly consult this privacy statement to stay informed of any changes. Additionally, we will endeavour to actively inform you of any amendments, wherever possible. ### **19.** **Contact Details** If you have any questions, our privacy team is here to help – please reach out to us at: Privacy Officer: Huzefa Olia 1Kosmos, Inc. Address: 1st Floor, 399 Thornall Street, Edison, NJ 08837 Website: Email: Phone number: +1 (833) 850-5464 # Cookie policy Digital identity verification and authentication software that verifies users, eliminates passwords, and stops fraud across workforce, customer, and resident identities. ### **1.** **Disclaimer** Our website,  (hereinafter: “the website”) uses cookies and other related technologies (for convenience all technologies are referred to as “cookies”). Our website uses cookies, in combination with pixels, local storage objects, and similar devices (collectively, “cookies” unless otherwise noted) to distinguish you from other users of the website. Cookies are also placed by third parties we have engaged. By using our website, you agree to the use of cookies and other technologies as set out in this Cookies Policy (“Policy”). We appreciate some users who may like more individual control over their visit to our website and can adjust their settings accordingly. You can read all about this in the section below “How to control and delete cookies”. If you do not agree with such use, please refrain from using the website. Through the information provided below we notify you about the use of cookies on our website and purposes for using them. ### **2.** **What are cookies** A cookie is a small file and holds a certain amount of data, which our website can send to your browser. It may then be stored on your computer’s hard drive and can be accessed by our web server. This cookie data can then be retrieved and can allow us to customize our web pages and services accordingly. It is important to clarify that cookies do not collect any personal data stored on your hard drive or computer. To enrich our website content, sometimes we may embed video content from other social media websites such as YouTube or Facebook. As a result, when you visit a page with content embedded, you may be presented with cookies from these websites. 1Kosmos has no control or liability over these cookies set, so you should check the relevant third party’s cookie policy for more information. ### **3.** **Types of cookies** * **Necessary Cookies:** Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data. * **Functional Cookies:** Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features. * **Analytics Cookies:** Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc. * **Performance Cookies:** Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors. * **Advertisement Cookies:** Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns. * **Others:** Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet. ### **4.** **How do we use cookies** We use cookies to enhance your browsing experience, improve the functionality of our website, and provide personalized services. Cookies help us understand how you interact with our site, enabling us to analyze usage patterns, optimize performance, and deliver relevant content. Additionally, cookies may be used for authentication, security, and to remember your preferences for future visits. These insights allow us to continuously improve our platform and ensure a secure and user-friendly experience. We use two analytics packages in order to constantly improve your browsing experience on our websites. Trusted partners and analytics companies like Google Analytics, Cloudflare & Hubspot may also place cookies on your machine. Please read their privacy policies to ensure that you’re comfortable with the manner in which they use cookies. * [Google Analytics](https://www.google.com/intl/en/policies/privacy/) * [Cloudflare](https://www.cloudflare.com/cookie-policy/) * [Hubspot](https://legal.hubspot.com/cookie-policy) ### **5.** **Third party cookies** To enrich our website content, sometimes we may embed video content from other social media websites such as YouTube or Facebook. As a result, when you visit a page with content embedded, you may be presented with cookies from these websites. 1Kosmos has no control or liability over these cookies set, so you should check the relevant third party’s cookie policy for more information. We also offer a “share page” widget on some of our web pages, where content can be shared easily on the following sites Facebook, Twitter, LinkedIn and Google+. These sites may set a cookie when you are logged into their service. 1Kosmos has no control or liability over these cookies set, so you should check the relevant third party’s cookie policy for more information. ### **6.** **Control & delete cookies** When you visit our website for the first time, we will show you a pop-up with an explanation about cookies. We provide three options when you visit our website – Accept all, Reject all and customize. 1Kosmos will not use cookies to collect personally identifiable information about you. You can use your internet browser to automatically or manually delete cookies. However, should you choose to disable, reject or block our cookies, some parts of our websites will not function fully, or in some cases, our website will not be accessible at all. Cookies on our website are stored for varying lengths of time depending on their purpose. Session cookies are temporary and expire once you close your browser, while persistent cookies remain on your device for a defined period, typically ranging from a few days to several months. Some cookies may stay longer if required for functionality or analytics, but you can delete them anytime through your browser settings. For more information on how to control your cookie settings and browser settings, or how to delete cookies on your hard drive, please visit . ### **7.** **Your Rights with Respect to Personal Data** Depending on your location, you have specific rights regarding personal data collected through cookies. These rights are outlined below: #### **7.1.** **Data Privacy Rights in India – \[Digital Personal Data Protection Act, 2023]** * Right of Access – Request confirmation and access to personal data collected through cookies. * Right to Correction and Erasure – Ask us to correct inaccurate data or erase data that is no longer necessary. * Right to Withdraw Consent – Revoke your consent for cookie usage at any time. * Right to Object – Object to processing of your data, except where processing is legally required. * Right to Nominate – Nominate another individual to exercise your rights in case of incapacity or death. * Right to Grievance Redressal – Raise concerns with us and, if unresolved, escalate to the Data Protection Board of India. #### **7.2.** **Data Privacy Rights in USA – \[California Consumer Privacy Act (CCPA/CPRA)]** * Right to Know – Request details about the categories of personal data collected via cookies, purposes, and any sharing with third parties. * Right to Delete – Ask us to delete personal data collected through cookies. * Right to Correct – Request correction of inaccurate personal data. * Right to Opt-Out of Sale/Sharing – Opt-out of the sale or sharing of personal data collected via cookies. * Right to Limit Use of Sensitive Data – Restrict the use of sensitive personal information. * Right to Data Portability – Request a copy of your personal data in a portable format. * Right to Non-Discrimination – Exercising your rights will not result in discriminatory treatment. #### **7.3.** **Data Privacy Rights in the European Union – \[General Data Protection Regulation (GDPR)]** * Right to Be Informed – Clear and transparent information about how cookies collect and use your data. * Right of Access – Request access to personal data collected via cookies and obtain a copy. * Right to Rectification – Correct inaccurate or incomplete data collected through cookies. * Right to Erasure (“Right to be Forgotten”) – Request deletion of your personal data when it is no longer necessary or consent is withdrawn. * Right to Restrict Processing – Limit the processing of your data under certain conditions. * Right to Data Portability – Obtain your personal data in a structured, machine-readable format. * Right to Object – Object to processing for purposes such as analytics or advertising. * Rights Related to Automated Decision-Making and Profiling – You have the right not to be subject to decisions based solely on automated processing that significantly affects you. To exercise these rights, please contact our privacy officer, as provided below. If you have a complaint about how we handle your data, we would like to hear from you. You also have the right to submit a complaint to the appropriate supervisory authority. ### **8.** **Amendments To This Policy** We reserve the right to modify our Policy to align with current legal and regulatory requirements. We recommend that you review this Policy from time to time to keep abreast of any updates. Furthermore, we will make an effort to proactively notify you about any alterations when feasible. ### **9.** **Contact** For any concerns with respect to this Policy please contact: **Privacy Officer:** Huzefa Olia **1Kosmos, Inc.** **Address:** 1st Floor, 399 Thornall Street, Edison, NJ 08837 **Website:** **Email:** **Phone number:** +1 (833) 850-5464 # Copyright Notice for 1Kosmos Inc. Product Source Code and Content ### **1. Ownership** The source code, content, and all associated intellectual property, including but not limited to text, graphics, logos, icons, images, audio clips, video clips, digital downloads, data compilations, and software (collectively referred to as “Product”), are the exclusive property of 1Kosmos Inc. and are protected by international copyright laws. The compilation of all content in this Product is the exclusive property of 1Kosmos Inc. ### **2. License** 1Kosmos Inc. grants you a limited, non-exclusive, non-transferable, revocable license to access and use the Product for its intended purpose, subject to the terms and conditions specified herein. This license does not include any resale or commercial use of the Product or its contents; any collection and use of any product listings, descriptions, or prices; any derivative use of this Product or its contents; any downloading or copying of account information for the benefit of another merchant; or any use of data mining, robots, or similar data gathering and extraction tools. ### **3. Restrictions** You may not, without express written permission from 1Kosmos Inc.: * Reproduce, duplicate, copy, sell, resell, or exploit any portion of the Product. * Modify, adapt, translate, reverse engineer, decompile, disassemble, or create derivative works based on the Product or any part thereof. * Use any meta tags or any other “hidden text” utilizing 1Kosmos Inc.’s name or trademarks without the express written consent of 1Kosmos Inc. * Use the Product or its content for any purpose that is unlawful or prohibited by these terms and conditions. ### **4. Disclaimer of Warranties and Limitation of Liability** The Product is provided by 1Kosmos Inc. on an “as is” and “as available” basis. 1Kosmos Inc. makes no representations or warranties of any kind, express or implied, as to the operation of the Product, the information, content, materials, or products included on this Product. You expressly agree that your use of the Product is at your sole risk. To the full extent permissible by applicable law, 1Kosmos Inc. disclaims all warranties, express or implied, including, but not limited to, implied warranties of merchantability and fitness for a particular purpose. 1Kosmos Inc. does not warrant that the Product, its servers, or email sent from 1Kosmos Inc. are free of viruses or other harmful components. 1Kosmos Inc. will not be liable for any damages of any kind arising from the use of the Product, including, but not limited to direct, indirect, incidental, punitive, and consequential damages. ### **5. Trademark Notice** All trademarks, service marks, trade names, and logos appearing on the Product are the property of 1Kosmos Inc. or their respective owners. Nothing contained on the Product should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any trademark displayed on the Product without the written permission of 1Kosmos Inc. or the third party that may own the applicable trademark. ### **6. Changes to this Notice** 1Kosmos Inc. reserves the right to modify this copyright notice at any time. Any changes will be effective immediately upon posting to the Product. ### **7. Contact Information** For inquiries or questions regarding this copyright notice, please contact: 1Kosmos Inc. 1 Tower Center Blvd suite 1510-17, East Brunswick, NJ 08816, United States \[+1 833-850-5464]]\(tel:833.850.5464) # Overview Verify any user, anywhere, with a single identity platform that combines document, biometric, and database checks into one privacy-first workflow.
Verification checks performed during a user's verification
1Kosmos Verify lets you confirm that the person on the other side of the screen is real, present, and exactly who they claim to be — and then keeps that identity reusable for everything that comes next: onboarding, account recovery, step-up authentication, and workforce or customer access. It combines government-issued document verification, certified live biometrics, non-document data checks, and AML/PEP/sanctions screening into a single configurable workflow. Every verified identity is bound to the user's device and stored as a reusable credential — so you proof the user once and reuse the result whenever you need to be sure. ### What you can do with 1Kosmos Verify Using 1Kosmos Verify, you can: * Onboard users from any country with support for thousands of government-issued ID types driver's licenses, passports, national ID cards, and residence permits. * Run certified live biometric capture with **LiveID** to defeat deepfakes, masks, photo replays, and injection attacks. * Perform document-free, **Non-Document Verification** by validating user-supplied data against authoritative sources such as AAMVA, the SSA, telco carriers, banking, and email reputation. * Read and cryptographically validate the chip on NFC-enabled passports and ID cards (ICAO 9303). * Screen applicants in real time against global sanctions, PEP, and adverse media watchlists for AML and CDD compliance. * Issue every successfully verified user a portable **Identity Wallet** that stores credentials encrypted on their device and can be reused anywhere 1Kosmos is integrated. * Configure **Identity Assurance Levels** (IAL1 / IAL2) on a per-flow basis to match the risk of each journey. * Review applicant cases, override decisions, and tune your workflow from the **1Kosmos Admin Portal** * Receive verification results in your own systems through REST APIs and webhooks, or drop in pre-built SDKs for web, iOS, and Android. ### How verification works A 1Kosmos Verify journey is a sequence of **verification steps** assembled into an **Identity Assurance Level**. Each step contributes evidence; the workflow engine combines them into a single decision and a single, reusable verified identity. A typical journey looks like this: {% stepper %} {% step %} #### Capture The user is prompted by your application, through a hosted page, embedded SDK, or the BlockID mobile app, to complete the steps you've configured. {% endstep %} {% step %} #### Evidence collection The user presents a document, takes a LiveID selfie, supplies non-document data (SSN, phone, email, banking), or answers a questionnaire, depending on the level. {% endstep %} {% step %} #### Validation 1Kosmos extracts data, verifies document authenticity, performs face match against the document portrait, runs liveness and presentation-attack detection, and cross-checks data against authoritative sources. {% endstep %} {% step %} #### Risk and compliance checks The applicant is screened against sanctions, PEP, and adverse media lists, and any risk signals (device, geolocation, document tampering) are evaluated. {% endstep %} {% step %} #### Decision Results are returned to your application as a single pass/fail outcome with full evidence detail. Edge cases route to a reviewer in the Admin Console. {% endstep %} {% step %} #### Bind and reuse On success, the verified identity is sealed to the user's wallet and made available for reuse across every relying party in your environment. {% endstep %} {% endstepper %} ### Verification methods 1Kosmos Verify offers a complete library of evidence types. Mix and match them in any Identity Assurance Level. #### Document verification Capture a government-issued ID with the camera, parse it with AI/ML-driven OCR and forensics, and check it for forgery, tampering, photo substitution, and template fraud. Extracted data is cross-referenced with issuing authorities such as the **AAMVA** for U.S. driver's licenses and **ICAO** for ePassports, **UIDAI** for Aadhar. Supported documents include driver's licenses, passports, national ID cards, residence permits, and Social Security cards. #### NFC chip verification For NFC-enabled documents (most modern passports and many ID cards), 1Kosmos mobile authenticator app reads the chip directly and validates the issuer's digital signature. This is the highest-trust form of document evidence and is required for IAL3-style flows. #### LiveID - liveness and face match **LiveID** is 1Kosmos's certified biometric. The user records a selfie; the system analyses image, texture, color, and 3D depth signals to confirm a live human is present, then matches the captured face against the document portrait. LiveID is certified to **iBeta PAD Level 2** under ISO/IEC 30107-3 and is part of 1Kosmos's NIST 800-63-3 IAL2 conformance. #### Non-Document Verification Verify identity without asking for a physical ID by validating user-supplied data against authoritative sources. 1Kosmos supports any combination of: * **SSN verification** against the Social Security Administration. * **Phone / telco verification** for carrier ownership, line type, and SIM-swap risk. * **Email verification** for ownership, age, and reputation signals. * **Banking credential verification** for name and account ownership. * **Address and KBA** checks against credit-bureau and utility data sources. You can use Non-Document Verification on its own for lower-friction journeys, or combine it with document verification — for example, falling back to documents if a non-doc check is inconclusive. #### AML, PEP, and sanctions screening Screen applicants against global sanctions lists (OFAC, UN, EU, HMT, and others), politically-exposed-persons databases, and adverse media at the moment of verification, and re-screen on an ongoing basis. Hits route to your reviewers as cases inside the Admin Console. #### Device and risk signals Every session is fingerprinted for device, IP, geolocation, and behavioral anomalies. Risk signals are surfaced alongside the identity decision so you can route, step up, or block. ## Identity Assurance Levels In 1Kosmos Verify, a **level** is a named, reusable configuration of verification steps that you assign to a journey (signup, recovery, high-value transaction, etc.). Levels map cleanly to NIST 800-63-3 Identity Assurance Levels: | Level | Typical use | Evidence | | -------- | -------------------------------------------------- | ----------------------------------------------------------- | | **IAL1** | Lightweight signups, anonymous access | Email + phone, optional selfie | | **IAL2** | KYC / AML, employee onboarding, regulated services | Government ID + LiveID + authoritative-source checks | | **IAL3** | High-assurance: financial, government, healthcare | NFC document read + LiveID + in-person or supervised remote | ## Compliance and certifications 1Kosmos Verify is built to satisfy the regulators and standards bodies that matter: * **NIST SP 800-63-3** — IAL2 conformant (Kantara-certified Full Service), with capabilities aligned to IAL3. * **FIDO2 Certified** — standards-based, phishing-resistant authentication paired with verified identity. * **iBeta PAD Level 2** — independently tested under ISO/IEC 30107-3 with zero false matches in iBeta's biometric trials on iOS and Android. * **W3C Decentralized Identifiers (DID)** — every wallet credential follows the open W3C DID standard. * **Privacy frameworks** — GDPR, CCPA, and HIPAA-aligned data handling, with user-held keys and no centralized PII store. # Core Concepts *** ### How they fit together A **flow** is your configuration. A **session** is one execution of that flow. The session produces a **result**, and — if the user is enrolled — writes verified attributes to their **identity wallet** at the appropriate **assurance level**. ``` Flow (config: docs allowed, liveness level, retention) │ └──▶ Session (one user, one URL, one outcome) │ ├──▶ Result (verdict + fields + scores) └──▶ Identity Wallet (durable, user-owned) │ └──▶ released to your app via OIDC / SAML / API only with explicit user consent ``` ### Mapping to common products If you've worked with another IDV vendor, the vocabulary translates: | 1Kosmos | Persona | Sumsub | Incode | | ------------------- | ------------ | ------------------ | ------------------ | | Verification flow | Template | Verification level | Onboarding flow | | Session | Inquiry | Applicant | Onboarding session | | Verification result | Verification | Review | Session outcome | | Identity wallet | Account | Applicant profile | Incode Identity | The differences matter most when you talk about data lifetime: a 1Kosmos identity wallet is owned by the **user** and persists across sessions and tenants, while most competitors store identity records inside the **business's** account. # Verification flow A reusable configuration that defines which checks run, on which documents, with what strictness.
Verification flows created by admins
### Overview A **verification flow** (also called a **journey**) is the reusable recipe that drives every session. You define one flow per use case, say, "high-risk onboarding for US banking" and reference it from your sessions by its unique tag. A flow answers four questions: 1. **What can the user submit?** Allowed countries, regions, and document types. 2. **What checks must pass?** Document authenticity, face match, liveness, database lookups, name comparison. 3. **How strict is each check?** Standard vs. Strict policy, liveness level, face-match score threshold, fuzzy-match tolerance. 4. **What happens to the data?** Retention policy, retry count, session expiry. ### Flow types 1Kosmos ships three pre-built flow types. Pick the one that matches your assurance and friction budget. {% tabs %} {% tab title="KYC with Selfie" %} **Document + biometric.** The user scans an ID and takes a selfie. 1Kosmos runs document authenticity, passive liveness, and face comparison against the photo on the ID. **Use when:** You need to bind a person to a document, onboarding, account recovery, age verification. This is the default for most consumer use cases. {% endtab %} {% tab title="Document Only" %} **Document, no biometric.** The user scans an ID and 1Kosmos validates it, but no selfie or face match is performed. **Use when:** You only need to confirm the document is genuine, for example, age gating, document re-enrollment, or B2B contexts where a biometric is overkill. {% endtab %} {% tab title="IAL2" %} **Two documents + biometric + SSN.** A Kantara-certified flow that produces a NIST 800-63-3 IAL2 result in one session. Sessions expire after 30 minutes by default and data is *not* persisted to a wallet unless you explicitly enable it. **Use when:** You're subject to federal identity proofing requirements, or you need the highest level of assurance for a one-time event. {% endtab %} {% endtabs %} ### Flow lifecycle {% stepper %} {% step %} **Create** An administrator with `idproofing.add-journey` opens **Verification → Verification Flows** in AdminX and walks through the three-step wizard. The flow is saved with a **unique tag** that your API callers use to start sessions. {% endstep %} {% step %} **Test** Generate sessions directly from the flow card in AdminX to QA the experience before going live. {% endstep %} {% step %} **Promote** Promote the same flow tag from your staging to production tenant, your application code doesn't change. {% endstep %} {% step %} **Tune** Edit the flow at any time. Existing in-flight sessions continue with the configuration they started with; new sessions pick up the change immediately. {% endstep %} {% step %} **Retire** Delete the flow when no session generation references it. You'll be prompted to confirm. Past sessions and their results are preserved. {% endstep %} {% endstepper %} ### Anatomy of a flow Every flow regardless of type exposes the same configuration surface: | Group | What you configure | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Use case** | Context (remote vs. in-person), Document Verification Policy (Permissive → Very Strict), and Retry Count. | | **Identification** | Journey name (human-readable) and unique tag (machine-readable, immutable). | | **Allowed documents** | Allow-list or block-list of document types, scoped by country and region. National vs. state formats are selected separately. | | **Expiration** | "From Session Creation" (how long the URL stays valid if untouched) and "From Session Start" (how long after the user opens it before it times out). | | **Data comparison** | Which user-provided fields are compared against extracted document fields. Fuzzy matching, ignore-middle-names, and DOB comparison live here. | | **Biometric** *(KYC with Selfie only)* | Liveness Level (Soft / Regular / Hardened) and Face Matching score threshold (0–100%, default 50%). | | **Data retention** | Discard immediately, discard after result is retrieved, or discard after N days/minutes. Applies per outcome (Success, Failed, Review, Abandoned). | # Session One user's attempt at a verification flow, with its own URL, expiry, status, and result. *** ### Overview A **session** is a single user's attempt at a verification flow. Every verification you run - whether you started it from AdminX, the API, an OIDC/SAML redirect, or a webhook callback produces exactly one session. ### What a session contains | Field | Description | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `sessionId` | Globally unique identifier. Use it to fetch results or cancel. | | `url` | The hosted verification URL. Hand this to the user any way you like. | | `journeyTag` | The flow this session was created against. | | `status` | `pending` → `in_progress` → terminal state. See the lifecycle below. | | `expiresAt` | When the session will time out if no further activity occurs. | | `referenceData` | The first name, last name, and DOB you supplied (optional, used for name/DOB comparison). | | `result` | Populated once the session reaches a terminal state. See [Verification result](/identity-verification/core-concepts/viewing-verification-results). | ### Lifecycle A session moves through a small state machine. Most paths converge on `success` or `failed`; a few branch off when the user walks away or your retention policy kicks in. ```mermaid stateDiagram-v2 [*] --> pending pending --> in_progress: user opens URL pending --> abandoned: expiresAt reached in_progress --> success: all checks pass in_progress --> failed: a required check fails in_progress --> review: needs manual review in_progress --> abandoned: user walks away success --> [*] failed --> [*] review --> [*] abandoned --> [*] ``` ### Status meanings * **pending** — Session created. URL is live but not yet opened. * **in\_progress** — User has opened the URL. Document or biometric capture may be in flight. * **success** — All required checks passed. `result` contains extracted fields and scores. * **failed** — A required check failed. `result.failureReason` tells you which one. Common reasons: document expired, face match below threshold, AAMVA mismatch, document type not allowed. * **review** — Verdict is ambiguous and requires a human reviewer. Only produced if your tenant has the manual-review queue enabled. * **abandoned** — Session expired or the user closed the tab before reaching a verdict. * **not\_performed** — A particular sub-check (e.g. AAMVA) couldn't run because the upstream system was unreachable. The session as a whole may still succeed depending on flow strictness. ### Expiry Two timers govern when a session ends. Both are configured on the flow. | Timer | Default (Configurable) | What it controls | | ------------------------- | ---------------------- | --------------------------------------------------------------- | | **From Session Creation** | 7 days | How long the URL is valid if the user never opens it. | | **From Session Start** | 60 minutes | How long the user has to complete, once they've opened the URL. | Once either timer elapses without a terminal state, the session moves to `abandoned`. # Viewing Verification Results This page explains how community and helpdesk administrators can view and interpret document verification session results. *** ### Access session results **From the Verifications page** - Navigate to **Verification > Verifications**, then click the specific session for which you want to view the results. ### View Results page The View Results page displays the following information: **Session Details** — A summary of the session, including Session Id, Session Status, Attempts, Created On, Operating System, and IP Address. **Summary** — An overview of the verification session, including the scanned document, verification results, and the reason for failure (if applicable). **Confidence Score** — Lists the attributes that passed the liveness check: * Document Liveness Front * Document Liveness Back * Fraud Detection **Fraud Detection** — Details the attributes used to detect fraudulent activity: * **Extracted Data Check** — Type of checks performed to detect fraud. * **Document Liveness** — Type of checks applied during liveness verification. * **Visual Check**- Displays visual fraud indicators including photo forgery check, security features, and generative AI detection. * **Document Validity** — Parameters checked during document validation. * **Image Quality** — Indicates whether the image met verification criteria. **Data Extracted** — Summarizes the details extracted from the document, including document type, document id, first name, last name, date of birth, and so on. **Images** — Displays the images captured during the verification process, including document photos and selfies. {% hint style="info" %} The image retention period is determined by the `pii_retention_policy` setting. If set to `0`, 1Kosmos does not store the data. Adjust this policy to define how many days data should be retained. {% endhint %} **Session Details** — Displays detailed information on the attributes extracted from the document. **Session Events** — Step-by-step status updates of the verification process: | Event | Description | | -------------------- | -------------------------------------------------------------------- | | Initialization | The session has been initialised. | | Welcome | The session has been started by the user. | | Document Instruction | The user received instructions for capturing document images. | | Document Capture | The user is capturing images of their ID. | | Document Preview | The user previewed the captured document. | | Selfie Instruction | The user is following the instructions for taking a selfie. | | Selfie Capture | The system successfully captured the user's selfie for verification. | | Selfie Preview | The user is currently previewing their selfie before submission. | | Document Submission | The user submitted their ID for verification. | | Validate Document | The system validated the document. | By following these steps, you can effectively manage the verification process and ensure accurate and secure document verification for your users. # AI Analysis Summary The AI Analysis Summary adds an AI-powered analysis layer to the verification results view. It takes the underlying verification signals and translates them into a clear, plain-language summary. *** ### Overview When an identity verification session fails, the question that matters most is simply *why*. Until now, 1Kosmos surfaced the raw check results. These are useful for engineers, but not always actionable for the operations teams, fraud analysts, and help desk staff who need to make fast decisions. The AI Analysis Summary adds an AI-powered analysis layer to the verification results view. It takes the underlying verification signals and translates them into a clear, plain-language summary of what happened, why the session was flagged, and what to do next. ### The verification results view For a completed verification session that has been flagged for manual review, a **status badge** at the outcome. A flagged session is one that did not outright fail but also did not fully clear; it is routed for a human decision before any approval is made. Core components * **AI analysis** — Contains everything a reviewer needs to make a decision. * **Documents** — Preserves full access to the underlying data. #### AI-powered IDV session analysis 1Kosmos generates an AI-powered summary for each Identity Verification (IDV) session, giving reviewers a plain-language breakdown of the verification outcome without requiring them to comb through raw session data. The summary is organized into three sections: **Session Overview** A concise summary of the verification session, covering the applicant, the document presented, and the overall outcome. This gives the reviewer an immediate snapshot before diving into the detail. **Failure Reasons** A plain-language explanation of any verification failures or flagged checks, identifying the cause of an unsuccessful or flagged session without requiring the reviewer to interpret raw signal data. **Key Findings & Recommendations** The likely cause of the outcome, along with actionable next steps. This is the section that drives the reviewer's decision - whether to approve, reject, or escalate for further investigation. ### Flagged checks The flagged checks section shows exactly what the AI evaluated and what it could not complete. In the example above, the image quality failure was the root cause, and because of it the following checks were not performed: * Field-level matching * Format checks * Bar code anomaly detection * MRZ parsing * Visual security feature validation The AI surfaces this as a structured breakdown, so the reviewer is not guessing at what is missing. They know precisely which checks need human eyes and which signals they can rely on. ### Decision panel The decision panel is located on the right side of the screen. Once the reviewer has assessed the AI summary and the flagged checks, they can optionally add a comment documenting their rationale, and then mark the session as **Approve** or **Reject** with a single click. # Assurance Levels NIST 800-63-3's scale for how much you can trust a verified identity, and where 1Kosmos sits on it. *** ### Overview **Identity Assurance Level (IAL)** is a NIST scale that describes how much evidence backs a claimed identity. The higher the IAL, the more rigor went into proving the person is who they say they are. 1Kosmos is **Kantara-certified at IAL2** — the level required by most US federal identity-proofing programs and a growing number of regulated industries. ### The three levels | Level | What it means | Typical use case | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | **IAL1** | Self-asserted. The user provides their own attributes; no verification is required. | Forum signup, newsletter, low-risk marketing accounts. | | **IAL2** | Identity proved with corroborating evidence. At least one **STRONG** piece of identity evidence (e.g. passport or driver's license) is verified with the issuing authority, plus a biometric binding to the holder. | Banking, healthcare, government services, regulated workforce onboarding. NIST 800-63-3-compliant. | | **IAL3** | In-person or supervised remote proofing with two **STRONG** pieces of identity evidence and an in-person biometric collection. | Federal employee badging, secure facility access, classified workflows. | ### What IAL2 actually requires NIST 800-63-3 IAL2 is more specific than "verify an ID." A compliant flow must: 1. **Collect at least one STRONG and one FAIR identity evidence** (or two STRONG), where STRONG includes a passport, REAL ID-compliant driver's license, or US permanent resident card. 2. **Validate the evidence with the issuing or authoritative source** — for US driver's licenses, this is AAMVA. 3. **Verify a binding between the evidence and the live applicant** — typically a selfie + liveness check matched against the document photo. 4. **Address record verification** for at least one piece of evidence, via authoritative source. 5. **Reasonable assurance of address of record** for follow-up notifications. ### How a session maps to an IAL The IAL of a finished session is a function of which checks ran and passed: ``` Document scan only → IAL1 (insufficient binding) Document + selfie + liveness + AAMVA → IAL2 (US DL) Document + selfie + liveness + AAMVA + SSN → IAL2 with stronger record verification Two documents + selfie + liveness + AAMVA + SSN→ IAL2 (Kantara-certified pattern) In-person proofing with two STRONG IDs → IAL3 (requires supervised flow) ``` # Manual Review & Manual Capture Manual Capture and Manual Review are fallback pathways. They must not be used as the primary route, always ensure the automated scan path is attempted first. *** ### Overview 1Kosmos IDV supports two fallback mechanisms for when a user cannot complete automated document scanning. Manual Capture is triggered when users who are unable to scan their ID automatically after repeated scan failures. The user does not need to select this mode manually, the system transitions them. | Fallback mode | Description | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manual Capture** | Share the identity verification session link from the Manual Capture workflow. The system automatically switches to Manual Capture mode, and the user takes still photos of the front and back of their ID. | | **Manual Review** | After images are submitted (via auto or manual capture), a 1Kosmos agent reviews the session and approves or rejects it manually. The user sees an **Under Review** status screen. | **Alternate device.** If a user cannot complete scanning on their current device, advise them to use an alternate device (for example, a smartphone with a better camera) and re-initiate the IDV link. Try this before escalating to Manual Capture. ### Supported documents The 1Kosmos IDV platform accepts a defined set of document types. Advise users to have one of these ready before starting the verification journey. See the [Supported Document List](/identity-verification/supported-documents). **Alternate ID (if primary fails).** If a user's primary ID cannot be scanned or is not accepted, advise them to try an alternate accepted document from the list. For example, if a driver's license fails, a passport may scan more reliably due to its flat, high-contrast layout. {% hint style="info" %} Worn, heavily laminated, or damaged documents may fail automated scanning. In these cases, Manual Capture is the recommended fallback — not a different document. {% endhint %} ### Alternate device guidance If a user's primary device cannot complete the scan, advise them to switch to an alternate device before escalating further. **Recommended steps:** 1. Ask the user to open the IDV link on a second device (smartphone preferred, tablet acceptable). 2. Confirm the alternate device has a working rear camera. 3. Re-send the IDV link, or have the user copy it, to the alternate device. 4. The user restarts the journey on the new device. Manual Capture will be available again if auto-scan fails. 5. If the alternate device also fails, escalate to Manual Review. ### Manual Review: what happens after submission Once a user completes Manual Capture (or any IDV session that requires additional verification), their session may be placed into Manual Review. The user sees: *"Under Review, Images submitted. Our team is reviewing your session."* #### What happens during Manual Review * A 1Kosmos reviewer (or designated agent) examines the submitted ID images and selfie. * The reviewer verifies document authenticity, legibility, and face match against the selfie. * The session is then approved or rejected in the AdminX. #### AAMVA check during Manual Review During the manual review process, 1Kosmos agents can run a database check to validate a driver's license or state ID. | AAMVA check detail | Description | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **What it verifies** | Confirms that the name, date of birth, license number, expiration date, and address on the submitted ID match the DMV record for that state. | | **When to run it** | During manual review, when the reviewer needs additional confidence in the document's authenticity. | | **When NOT to run it** | When the issuing state is not in scope for AAMVA. Check with your 1Kosmos admin for the current in-scope state list. | ### Common issues * **Image quality** — Without automated quality gates, users may submit blurry, poorly lit, or cropped images, increasing IDV0001 failures and hard stops. * **OCR extraction** — Poor image quality leads to misread or missing fields (DOB, document number, name), driving Data Match and Format check failures and inflating manual review volume. # Event Reference This page lists every event type recorded in the 1Kosmos Event Logs for ID Verification, along with the fields captured for each event. Events are grouped by activity category so you can quickly find *** ### **How to read an entry** Each event below includes: * **Event code** — the identifier that appears in the logs (for example, E\_IDV\_INITIALIZATION). * **Name** — a plain-language description of what the event represents. * **Notes** — any conditions that affect when the event is recorded, where applicable. * **Fields captured** — the data fields included in the event's payload. Note: If the internet is unavailable at any stage of the verification process, no events are triggered. ### **ID Verification Activity** **E\_IDV\_INITIALIZATION — ID verification session started** Triggered when a user begins their ID verification process on the Initialization screen. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `screen_name` , `status` , `SessionInfo._id` , `SessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.username` , `user.firstname` , `user.lastname` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_USER\_CONSENT — User consent captured** Triggered when a user gives consent for sharing their information. Verification status is "In Progress" while reading the consent notice and becomes "Completed" after consent is given. Note: If a user declines the consent notice, the event is triggered with status "Declined" and the user is prompted to reinitiate verification. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `screen_name` , `status` , `SessionInfo._id` , `SessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.username` , `user.firstname` , `user.lastname` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_DOCUMENTINSTRUCTION — Document instructions reviewed** Triggered when a user reviews the instructions before starting the document scan. Fields captured: `screen_name` , `status` , `eventCategory` , `event_name` , `type` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `sessionInfo._id` , `sessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.firstname` , `user.lastname` , `startedTS` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_DOCUMENTPREVIEW — Document preview displayed** Triggered when a user previews their document before capturing it. Fields captured: `screen_name` , `status` , `eventCategory` , `event_name` , `type` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `SessionInfo._id` , `SessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `username` , `lastname` , `startedTS` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_DOCUMENTCAPTURE — Document captured** Triggered when a user scans their document for capture. Verification status is "In Progress" during capture and becomes "Completed" after capture. Note: If an unsupported document is presented, the event is triggered with status "Verification Not Performed" with one of the following reason codes: "Unsupported document", "No document was presented", or "Document scan not completed. Please try again." Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `screen_name` , `status` , `SessionInfo._id` , `SessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.username` , `user.firstname` , `user.lastname` , `document_liveness_front_classInfo` , `document_liveness_back_classInfo` , `document_liveness_front` , `document_liveness_back` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_SELFIEINSTRUCTION — Selfie instructions reviewed** Triggered when a user reviews the instructions before taking their selfie. Fields captured: `screen_name` , `status` , `eventCategory` , `event_name` , `type` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `sessionInfo._id` , `sessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.firstname` , `user.lastname` , `startedTS` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_SELFIEPREVIEW — Selfie preview displayed** Triggered when a user previews their selfie before tapping the capture button. Fields captured: `screen_name` , `status` , `eventCategory` , `event_name` , `type` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `sessionInfo._id` , `sessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.firstname` , `user.lastname` , `startedTS` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_SELFIECAPTURE — Selfie captured** Triggered when a user captures their selfie. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `screen_name` , `status` , `sessionInfo._id` , `sessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.firstname` , `user.lastname` , `startedTS` , `selfie_liveness.docType` , `selfie_liveness.docId` , `selfie_liveness.type` , `selfie_liveness.authority` , `selfie_liveness.proofedBy` , `selfie_liveness.ts` , `selfie_liveness.verified` , `selfie_liveness.result` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_DOCUMENT\_SUBMISSION — Document submitted** Triggered when a user submits their scanned document. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `screen_name` , `status` , `SessionInfo._id` , `SessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.username` , `user.firstname` , `user.lastname` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_SESSION\_ABANDONED — Session abandoned** Triggered when a session is marked as Abandoned. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `sessionInfo._id` , `sessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `status` , `maxRetries` , `expiryTS` , `createdTS` , `user.firstname` , `user.lastname` , `expireSessionInMin` , `abandonSessionInMin` , `abandonedTS` , `startedTS` , `screen_name` , `reason` , `attemptIndex` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_SESSION\_EXPIRED — Session expired** Triggered when a session is marked as expired. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `sessionId` , `sessionInfo._id` , `sessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `status` , `maxRetries` , `expiryTS` , `createdTS` , `user.firstname` , `user.lastname` , `expireSessionInMin` , `abandonSessionInMin` , `screen_name` , `reason` , `attemptIndex` , `request_id` , `ts` , `app_id` , `uuid` , `journeyId` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` **E\_IDV\_DOCUMENT\_VALIDATE — Document validated** Triggered when a submitted document is validated. Note: If an unsupported document is presented, the event is triggered with status "Verification Not Performed" with reason code indicating an unsupported document was presented. Fields captured: `eventCategory` , `type` , `event_name` , `version` , `event_ts` , `ip_address` , `user_agent` , `sessionId` , `screen_name` , `status` , `SessionInfo._id` , `SessionInfo.id` , `dvcID` , `tenantDNS` , `tenantId` , `communityName` , `communityId` , `documentType` , `expiryTS` , `createdTS` , `user.username` , `user.firstname` , `user.lastname` , `startedTS` , `completedTS` , `resultStatus` , `document_firstname` , `document_lastname` , `document_id` , `document_expiry` , `request_id` , `app_id` , `event_id` , `timestamp` , `epoch_time` , `tenant_id` , `community_id` , `eventName` # Verification Methods The catalog of checks you can run inside a flow — pick the combination that fits your risk and friction budget. *** #### Verification methods A verification flow is built from one or more **methods**. Each method answers a specific question about the user. | Method | Question it answers | Friction | | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -------------- | | [Document verification](/identity-verification/verification-methods/document-verification) | Is the document the user submitted real, current, and unmodified? | Low–Medium | | [Biometric & liveness](/identity-verification/verification-methods/biometric-and-liveness) | Is the person holding the document the same person pictured on it — and present right now? | Medium | | [Database verification](/identity-verification/verification-methods/database-verification) | Do authoritative sources (AAMVA, SSA) corroborate the submitted data? | None (passive) | | [SSN verification](/identity-verification/non-doc-verification/ssn-verification) | Is the SSN provided real, and does it belong to the verified user? | Low | | [Notarized document bypass](/identity-verification/verification-methods/notarized-document-bypass) | Has this user already been verified by a trusted notary or partner? | None | | [Web-to-mobile handoff](/identity-verification/verification-methods/web-to-mobile-handoff) | Can the user finish capture on a phone after starting on desktop? | Low | #### Picking a combination Higher friction generally means higher assurance. The right combination depends on what you're protecting. {% tabs %} {% tab title="Low risk — newsletter, free tier" %} **Email verification only** (no IDV). No need for document verification. Save the user the friction. {% endtab %} {% tab title="Medium risk — paid SaaS" %} **Document verification** + **biometric & liveness**. Bind a real person to a real ID. Adequate for most B2C consumer apps and SaaS sign-ups. {% endtab %} {% tab title="High risk — banking, healthcare" %} **Document** + **biometric & liveness** + **database** + **SSN**. Document scan with face-match, AAMVA lookup against the issuing DMV, and SSN check. Equivalent to NIST IAL2. [Run a Kantara IAL2 flow →](/identity-verification/ial2-verification/create-and-manage-ial2-verification) {% endtab %} {% tab title="Very high risk — federal, classified" %} **Two STRONG documents** + **biometric & liveness** + **database** + **SSN** + **in-person or supervised remote**. Required for IAL3. Often combined with an in-person notary step, which 1Kosmos accommodates via [notarized document bypass](/identity-verification/verification-methods/notarized-document-bypass). {% endtab %} {% endtabs %} #### What happens at runtime When a session runs against a flow, each configured method becomes a step in the user's UI *and* a check on the server. The user-facing order is fixed (document → selfie → optional SSN entry), but the server-side checks run in parallel where possible. A failure in any **required** method fails the overall session. A failure in an **advisory** method (e.g. AAMVA where the upstream is unreachable) is downgraded to `not_performed` and doesn't block the result, unless your flow's strictness explicitly requires it. # Document Verification Scan a government-issued document, validate it server-side, and extract fields with field-level confidence scores. *** ### Overview Document verification asks one question: *"Is the document the user submitted real, current, and unmodified?"* It's the foundation of every higher-assurance flow. The user scans the front and (where applicable) back of an identity document. 1Kosmos checks the document's security features, parses its MRZ or barcode, validates internal checksums, OCRs the printed fields, and returns a structured payload with a per-field confidence score. ### What 1Kosmos checks For every submitted document, the analyzer runs a battery of checks: * **Image quality** — focus, glare, exposure, and edge detection. Failing images prompt the user to recapture. * **Document classification** — match against the country + region + type template library to identify which document was submitted. * **Security features** — holograms, microprinting, UV patterns, ghost images, and tactile features (where capture quality permits). * **MRZ / barcode** — checksum validation and field cross-check against the visual zone. * **Field consistency** — DOB vs. age, document number vs. region pattern, expiry vs. issue date. * **Expiry** — IDs past their expiry date are rejected by default (configurable per flow). * **Template integrity** — fonts, layout, and field positions are compared against the known template for that document version. Modifications, replacements, and digital injections are flagged. ### Enrolling a document in a wallet — the user experience End users go through the same UI regardless of which document they're enrolling. The example below uses a driver's license; passport, ID card, and SSN flows are identical except where noted. #### Driver's License {% stepper %} {% step %} #### Open the Identity Wallet The user signs in to your portal and navigates to **My Profile → Identity Wallet**. {% endstep %} {% step %} #### Click Enroll on the Driver's License tile The Driver's License tile in the Identity Wallet. {% endstep %} {% step %} #### Enter a phone number to receive the verification link The user enters their mobile number with country code. 1Kosmos sends a one-time link by SMS. {% endstep %} {% step %} #### Open the link on the phone The user taps the SMS link, lands on the verification start screen, accepts the consent, and taps **Let's Get Started**. {% endstep %} {% step %} #### Scan front and back The user holds the ID in frame. Auto-capture fires when focus, glare, and edge detection all pass. The UI flips to the back side automatically. {% endstep %} {% step %} #### Take a selfie The user holds the ID in frame. Auto-capture fires when focus, glare, and edge detection all pass. The UI flips to the back side automatically. {% endstep %} {% step %} #### See it land in the wallet Once all server-side checks pass, the document is signed into the user's wallet and the AdminX UI updates to show the new credential. {% endstep %} {% endstepper %} {% hint style="info" %} **SSN enrollment requires a prior DL.** You can only enroll a Social Security Number *after* a driver's license has been verified for the same user. The wallet uses the DL as the binding evidence. {% endhint %} **Passport** The flow is identical to driver's license, with three differences: * The user is prompted for the **bio-data page** rather than front/back. * The MRZ on the bio-data page is read and cross-checked. * AAMVA is not performed (it's US DL-only). For US passports, no equivalent database check is run unless your flow includes a separate SSN step. **National ID Card** Same flow as driver's license. Country-specific templates determine which fields are extracted, for example, Indian PAN cards extract the PAN number, German eIDs read the chip data via NFC where supported by the device. **Social Security Number** The SSN flow is **data-only,** no document scan. The user enters their SSN, 1Kosmos cross-checks it against the previously enrolled driver's license, and (with proper configuration) hits the SSA / eCBSV database. #### Unenrolling a document in a wallet A user can remove a credential from their wallet at any time from the Identity Wallet tab. The credential is revoked, future relying-party requests for that document will see it as withdrawn, but past audit records remain. {% hint style="warning" %} **Unenrolling a driver's license cascades.** Because the SSN credential is bound to the DL, revoking the DL also revokes the SSN. The user must re-enroll the DL first if they want to restore the SSN. {% endhint %} #### Extracted fields Every successful verification adds an `extracted` payload to the result. Fields available depend on document type. The most common: | Field | DL | Passport | ID Card | Notes | | ---------------- | -- | -------- | ------- | --------------------------------------------- | | `firstName` | ✓ | ✓ | ✓ | | | `lastName` | ✓ | ✓ | ✓ | | | `dob` | ✓ | ✓ | ✓ | ISO-8601 | | `documentNumber` | ✓ | ✓ | ✓ | | | `issuedAt` | ✓ | ✓ | ✓ | | | `expiresAt` | ✓ | ✓ | ✓ | Documents past expiry are rejected by default | | `address` | ✓ | | partial | Country-dependent | | `mrz` | | ✓ | partial | Available on MRTD-compliant documents | | `gender` | ✓ | ✓ | partial | | | `nationality` | | ✓ | partial | | # Biometric and Liveness Bind a real, present person to the photo on their document passively, in seconds, without prompts to blink or turn. *** ### Overview A document scan proves the document is real. A biometric and liveness check proves the **person holding it** is real, present, and the same person pictured on the ID. 1Kosmos runs both as a single, passive step. The user is asked for one selfie. Behind the scenes: 1. **Face detection** locates and aligns the face. 2. **Passive liveness** scores the capture for signs of a printed photo, screen replay, deepfake, or 3D mask. 3. **Face match** compares the live capture against the portrait extracted from the document. There are no blink prompts, head turns, or "say a sentence" challenges by default. The whole step takes 3–5 seconds. ### Liveness levels A flow's **Liveness Level** sets how aggressive the passive-liveness model is. You're trading off false rejections (turning away genuine users) against false acceptances (letting a spoof through). | Level | False reject | False accept | When to use | | ------------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------- | | **Soft** | Lowest | Highest | Re-verification, recovery flows, anywhere a genuine user struggling to capture is a worse outcome than a borderline spoof. | | **Regular** | Balanced | Balanced | Default. Right for the vast majority of consumer KYC and SaaS onboarding. | | **Hardened** | Highest | Lowest | High-value accounts, financial onboarding, situations where you'd rather lose a user than admit a spoof. | The level is set per flow under **Step 2: Face Liveness Settings**. {% hint style="info" %} **You can switch levels per flow, not per session.** If your risk model needs different strictness for different user segments — say, soft for re-verification and hardened for first-time onboarding — create two flows and pick the right one when generating the session. {% endhint %} ### Face matching score After liveness, the live selfie is compared to the portrait on the document. The result is a **similarity score** between 0.0 and 1.0. * The flow sets a **threshold** — the minimum score required to pass. Default is 0.50. The recommended range is 0.50–0.80. * Lowering the threshold accepts more genuine variations (lighting, age, glasses) at the cost of accepting more lookalikes. * Raising the threshold tightens the match. Above 0.85, expect to start failing legitimate users beards regrown, weight changes, older document photos. The threshold is set per flow on the same screen as liveness level. ### What the user sees {% stepper %} {% step %} **Permission prompt** The browser asks for camera permission. 1Kosmos checks the camera meets the minimum {% endstep %} {% step %} **Begin selfie** The UI displays an oval frame and a single CTA. {% endstep %} {% step %} **Position and capture** The user centers their face in the oval. Auto-capture fires when alignment and quality thresholds are met. No instructions to blink or move. {% endstep %} {% step %} **Result** A success screen appears. The user has no insight into the score only the verdict to preserve robustness against tuning by adversaries. {% endstep %} {% endstepper %} ### Anti-spoofing coverage The passive-liveness model is trained against the following Presentation Attack Instrument (PAI) categories: * **Print attacks** — printed photos, magazine cutouts, paper masks. * **Replay attacks** — phone, tablet, and laptop screen replays of a still photo or video. * **3D mask attacks** — silicone, latex, and paper masks. * **Deepfake attacks** — synthetic faces injected via virtual camera drivers. * **Cut-out attacks** — eye- and mouth-hole cutouts in printed photos. 1Kosmos's PAD (Presentation Attack Detection) is iBeta Level 2 certified to ISO 30107-3. {% hint style="info" %} **Injection attack defense.** Beyond what's visible in the camera frame, 1Kosmos detects attempts to inject pre-recorded video through virtual camera drivers — the most common deepfake delivery vector in 2026. This runs on every session at no extra configuration. {% endhint %} ### Edge cases worth knowing * **Lighting.** Backlit and very dim captures get a retry prompt. Liveness models cope with normal indoor lighting; harsh sun directly behind the user is a common failure case. * **Children.** Face match is less reliable on subjects under 13. The face-match threshold should be lowered, or the use case routed to a manual-review queue. * **Identical twins.** 1Kosmos's models cannot reliably distinguish identical twins; if your use case must, pair the face match with an additional knowledge-based or biometric factor. # Non-Doc verification Verify identity using authoritative data sources and possession signals, no document scan required. *** ## Overview Non-document verification is the catch-all for methods that establish a user's identity without asking them to capture a passport, driver's license, or national ID card. Instead of extracting attributes from a document image, these methods rely on authoritative data sources government registries, credit bureaus, mobile network operators, national eID schemes to confirm the user is who they claim to be. The trade-off versus document verification is straightforward: lower friction and faster completion, in exchange for narrower geographic coverage and (usually) lower assurance. For the right use cases, that's an obvious win. For others, document capture is still the right answer. This page covers when to reach for non-document methods and what's in the toolbox. ### How it works in general The exact flow depends on the method, but the shape is consistent: {% stepper %} {% step %} **The user provides an identity anchor** The user enters one or more attributes — typically a national identifier (SSN, national ID number), a phone number, or authenticates with an existing credential (eID, bank login). No camera, no document upload. {% endstep %} {% step %} **The platform queries an authoritative source** The submitted anchor is checked against the corresponding source of truth: the SSA for US SSNs, a credit bureau for attribute matching, a mobile network operator for phone-based intelligence, or a government/bank eID provider for federated identity assertions. {% endstep %} {% step %} **The source returns a verification signal** The response is either a yes/no match, a probabilistic match score, a signed identity assertion, or a fraud/risk signal depending on the source. The platform aggregates whatever was returned into a structured result. {% endstep %} {% step %} **Optional supplementary checks run** The flow can layer additional signals on top possession (OTP, silent network authentication), behavioural fraud indicators, or a lightweight biometric. These don't replace the primary check, but they reinforce assurance. {% endstep %} {% endstepper %} ### Methods in this category | Method | What it checks | Geographic fit | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | **eID** | Government-issued or bank-issued electronic identity (eIDAS, BankID, MitID, itsme, FranceConnect, and similar). Returns signed verified attributes at the scheme's assurance level. | Strong in EU, Nordics, Benelux, Baltics; limited elsewhere. | | **SSN verification** | Matches a US Social Security Number plus name and DOB against authoritative sources (eCBSV from SSA, credit bureau attribute matching, death indicator, issuance-date check). | US only. | | **Phone-based verification** | Mobile carrier intelligence (line type, tenure, SIM-swap, port-out, subscriber name/address) combined with possession checks (OTP, silent network authentication, voice call). | Global, with richest data in markets where MNO data sharing is mature. | # Database Verification Cross-check user-submitted data against authoritative government and carrier databases — AAMVA, eCBSV, SSA. *** ### Overview A document scan tells you the ID looks real. A database verification tells you the ID **is** real - that an authoritative source agrees the document number, name, and DOB belong together. 1Kosmos integrates directly with the issuing authorities. No third-party data brokers; no aggregated, stale snapshots. ### Available databases | Database | Region | What it validates | Latency | | ---------------- | ------ | -------------------------------------------------------------------------------------- | ------- | | **AAMVA** | US | Driver's license / state ID against the issuing state DMV record | <2 s | | **eCBSV / SSA** | US | SSN matched to first name, last name, and DOB | <3 s | | **DMV barcode** | US | PDF417 barcode on a US DL cross-referenced against the visual zone | inline | | **MRZ checksum** | Global | ICAO 9303 MRZ check digits — passports, ICAO-compliant national IDs, residence permits | inline | ### AAMVA When the user enrolls a US driver's license or state ID card, 1Kosmos sends the extracted fields to the **American Association of Motor Vehicle Administrators (AAMVA)**. AAMVA routes the request to the issuing state's DMV and returns a match/mismatch verdict per field. A passing AAMVA response means the issuing state agrees the document is genuine and the holder details match. This is the database check that takes a session from "looks authentic" to NIST 800-63-3 STRONG evidence. {% stepper %} {% step %} #### User completes DL scan The scan and selfie are accepted by the document analyzer. {% endstep %} {% step %} #### Result is verified by AAMVA Once your driver's license or ID card and selfie photo are accepted, your information is automatically verified through the American Association of Motor Vehicle Administrators (AAMVA). This step confirms that the ID is authentic and that the information matches records from the issuing state's DMV. {% endstep %} {% step %} #### Inspect details The user (and you) can open **Show Details** on the result tile to see which fields matched. {% endstep %} {% endstepper %} ### eCBSV / SSA SSN verification For US SSN enrollment, 1Kosmos can run an eCBSV (electronic Consent Based SSN Verification) check the SSA's authoritative API for confirming an SSN matches a name and DOB. eCBSV requires explicit user consent, captured during the SSN enrollment flow. ### Document checksums and barcodes For every supported document, 1Kosmos runs inline checks that don't require an external API call: * **PDF417 barcode** on US driver's licenses parsed, decoded, and cross-checked against the visual OCR. Any mismatch is flagged. * **MRZ check digits** on passports and ICAO 9303-compliant documents recomputed and compared. A bad checksum is an immediate document-authenticity failure. ### When a database check fails A `fail` from AAMVA or eCBSV is usually one of three things: 1. **Data entry mismatch** — the user mistyped a field, or the OCR misread an unusual character. Allow a retry. 2. **Document fraud** — the document number genuinely doesn't exist in the issuer's records. Route to manual review or hard-fail. 3. **Stale data** — the user moved recently and the DMV record hasn't propagated. Allow a re-attempt with corrected data or route to manual review. You can tune your flow's `retryCount` to control how many database-fail retries are allowed in a session before it terminates. # Notarized Document Bypass Bypass document scanning by having an administrator add a notarized affidavit to a user's wallet. *** ### Overview 1Kosmos enables community/helpdesk administrators to add an affidavit to a user's web wallet, allowing them to become IAL2 certified users without the need to physically scan their documents. An affidavit in 1Kosmos is a declaration made by the administrator certifying the authenticity of another user's Passport (PPT), Driving License (DL), or SSN. The administrator who creates the affidavit assumes responsibility for verifying the accuracy of the document. ### Why you'd use it It lets a user reach **IAL2 certification without physically scanning their documents**. This is useful when document capture isn't practical or has already happened in person for example, when a user's identity has been confirmed face-to-face using notarized physical copies and you want that in-person check reflected in their wallet. Because the administrator certifies the document, they take on responsibility for its accuracy, which is what makes the affidavit a valid substitute for an automated scan. ### Where it lives The affidavit is added from **Users > All Users** in AdminX by an authorized administrator, and it is stored in the user's **Identity Wallet**. The user can view it under **Dashboard > My Profile > Identity Wallet**, but cannot delete it. ### How it helps * Removes the document-scanning step for users who have already been verified through notarized physical copies. * Extends IAL2 enrollment to situations where automated capture isn't an option. * Keeps the verification evidence in the same wallet as scanned documents, so downstream relying parties treat it consistently. * Produces an auditable record an `E_AFFIDAVIT_ISSUED` event is logged whenever an affidavit is added (see Event logs). {% hint style="warning" %} Only administrators with **all** of the following permissions are authorized to add an affidavit: * `user.affidavit.add` * `users.view-user` * `users.edit` * `users.all-users` {% endhint %} ### Prerequisites To add an affidavit, you need the following details for the document: * Document type * Expiry * Document number ### Adding an affidavit {% stepper %} {% step %} **Log in as a community administrator** Log in to a tenant as a community administrator. {% endstep %} {% step %} **Open the user** Navigate to **Users > All Users** and select the user for whom you want to add the affidavit. {% endstep %} {% step %} **Start the affidavit** Click **...** and select **Add an affidavit**. {% endstep %} {% step %} **Enter the document details** In the **Add Verification Evidence** window, select the document you want to add as an affidavit, then enter the document number and the expiry date of the document. {% endstep %} {% step %} Click **Save**. The UI confirms that the new evidence has been added. {% endstep %} {% endstepper %} # Web-to-Mobile Handoff Let users start verification on desktop and seamlessly continue on their phone no manual link copying. *** Most desktops and laptops don't have a camera that's good enough to capture an ID document and most users would rather not hold their license up to a webcam anyway. 1Kosmos's **web-to-mobile handoff** lets the user start a verification on whatever device they signed up on, and seamlessly move to their phone for the capture step. The user never has to copy a link, type a code, or find the SMS app. ### How it works {% stepper %} {% step %} #### User starts on desktop They click your "Verify your identity" CTA. Their browser opens the session URL on the desktop. {% endstep %} {% step %} #### 1Kosmos checks camera capability The session detects the desktop browser doesn't meet the minimum camera resolution (1080×1920) — or simply isn't a camera-capable form factor. {% endstep %} {% step %} #### A QR code appears The desktop UI displays a QR code with a one-time, session-bound handoff URL. The session is **not yet started** on the mobile side it's just an invitation to continue. {% endstep %} {% step %} #### User scans the QR with their phone The same session same `sessionId`, same flow, same expiry opens on mobile. The desktop UI updates in real time to show "Verification in progress on mobile… {% endstep %} {% step %} #### User completes capture on mobile Document scan and selfie are captured on the phone. On completion, the desktop UI advances to the result screen. {% endstep %} {% endstepper %} #### When it triggers The QR handoff is offered automatically when any of these is true: * No camera is detected on the desktop browser. * The desktop camera resolution is below the 1080×1920 minimum. * The user explicitly clicks "Continue on phone" on the start screen. If the desktop camera *is* adequate (some laptops have very good ones), the user can continue on desktop. The QR option is still shown as an opt-in alternative. #### Session continuity guarantees * The `sessionId`, expiry, and result are shared across desktop and mobile. There's no second session created on handoff. * The result is delivered to **both** browser contexts. Whichever the user closes first, the other still receives the update. * Handoff URLs are bound to a single session and become invalid after first use. #### Edge cases * **User abandons on mobile.** The desktop UI continues to wait until the session's `from_session_start` expiry. After that, the session moves to `abandoned`. * **User reopens the QR after using it.** The handoff URL has already been consumed; the user is shown a "this link has expired" screen with a button to start over. * **Two devices race the handoff.** The first successful capture wins; subsequent submissions are rejected with `session_already_terminal`. # 1Kosmos as a Credential Service Provider (CSP) How 1Kosmos performs identity proofing as a Credential Service Provider (CSP), aligned with NIST SP 800-63A enrollment and identity proofing requirements. *** ### Overview NIST Special Publication [800-63A Enrollment and Identity Proofing](https://pages.nist.gov/800-63-3/sp800-63a.html) provides detailed requirements and controls for the enrollment and identity proofing of individuals into digital identity systems. Identity proofing is the process by which a Credential Service Provider (CSP) collects and verifies information about a person in order to issue credentials to that person, as illustrated below: These identity proofing processes, controls, and requirements are presented in [NIST SP 800-63A](https://pages.nist.gov/800-63-3/sp800-63a.html) to achieve the following processing objectives: * **Resolve** a claimed identity to a single, unique identity within the context of the population of users served by the CSP. * **Validate** that all supplied evidence is valid (correct) and genuine (not counterfeit or misappropriated), and that the claimed identity exists in the real world. * **Verify** that the claimed identity is associated with the real person supplying the identity evidence. # Configurations Community administrators—or users with the idproofing.add-journey permission—can create and manage verification journeys in the AdminX interface under Verification > Verification Flows. *** ### Configuring Verification Flows | Journey Type | Description | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **KYC with Selfie** | Combines document verification with face liveness and selfie matching. Users are prompted to scan an identity document and then capture a selfie for comparison. | | **Document Verification Only** | Enables standalone document verification without any selfie or liveness check. | Each journey is created in three steps: 1. **Select workflow type** — Choose between **KYC with Selfie** or **Document Verification Only**, and provide details such as the workflow name, type, last modified date, and creator. 2. **Select verification configuration** — Restrict allowed documents by country, region, and type; configure PII data retention policies; and enable first and last name matching for identity comparison. 3. **Manage face liveness and face matching threshold** — Configure Face Liveness (**Soft**, **Regular**, or **Hardened**) and set the Face Comparison Threshold (default: **50%**) to control the sensitivity of biometric matching. *** ### Configuring KYC with Face Comparison The KYC with Face Comparison journey consists of two main steps: 1. **Defining documents for verification** — Specify the list of documents accepted for verification. 2. **Configuring face liveness settings** — Set the liveness calibration and face matching threshold. **Step 1: Defining Documents for Verification** | Field | Description | | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Journey Name** | Specify a name for the verification journey. | | **Unique Tag** |

Specify a unique tag used by API callers to create sessions. The tag must be unique and cannot be changed once set.

Allowed characters: /^\[a-zA-Z0-9\_-]\*$/i

| | **Allowed Document Types** |

Select which document types are permitted for verification based on country and region. Only the selected types are accepted.

By default, the Allow toggle is selected and the Allowed Document Types dropdown is displayed. Switching the toggle to Block displays the Blocked Document Types dropdown instead, where you select the documents to restrict.

• In the Allowed Document Types window, click Allow all documents to permit all supported documents.

• Specify the country and region to narrow down which documents are available for selection.

The region determines whether the document format is national (used across the country) or regional (specific to a state or locality):

• Region: National — the document follows a country-wide format.

Example: Country: India, Region: National, Document Type: Driver License → Displayed as INDIA, DRIVER LICENSE. Although NATIONAL is not shown in the label, this refers to a standardized national document format.

• Specific region (e.g., state)

Example: Country: India, Region: Andhra Pradesh, Document Type: Driver License → Displayed as INDIA, ANDHRA PRADESH, DRIVER LICENSE.

National and regional formats must be selected individually — choosing one does not automatically include the other.

| | **Allow/Block Toggle** | Choose whether the selected documents are explicitly allowed or blocked. | | **Data Configuration** |

Specifies how long verification data is retained for each session outcome (Success, Failed, Not Performed, Review, and Abandoned). Options:

• Discard data immediately

• Discard data after caller retrieves result

• Discard data after specified time

| | **Discard Data After** *(appears only when **Discard data after specified time** is selected)* | Specify the number of days or minutes after which the verification data is discarded. | **Use Case** | Field | Description | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Context** | Defines the verification use case, such as remote or in-person verification. | | **Document Verification Policy** | Sets the policy for document analysis. **Standard** is recommended for most use cases. Options: Permissive, Standard (recommended), Strict, Very Strict. | | **Retry Count** | Maximum number of retry attempts allowed during the verification process. | **Expiration Intervals** | Field | Description | | ------------------------- | ---------------------------------------------------------------------------- | | **From Session Creation** | Sets how long a session remains valid if it has not been accessed. | | **From Session Start** | Sets how long a session remains valid after it has been started by the user. | **Data Comparison** | Field | Description | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Select from the list** | Choose which user data (e.g., First name, DOB) is compared against document data. | | **Ignore middle names** | When enabled, middle names are excluded from name comparison during ID proofing to improve match accuracy between directory data and identity documents. Only the first word of the first name is evaluated from both the user metadata and the identity document; any additional names in the document's first name field are ignored. Last name comparison behavior is unchanged. | | **Fuzzy Match (First Name)** | Enables approximate matching for the first name. Useful for handling spelling variations. | | **Fuzzy Match (Last Name)** | Enables approximate matching for the last name. | | **Fuzzy Match Slider** | Adjusts the threshold for fuzzy matching (recommended range: **70–80%**). | | **Date of Birth Comparison** | Compares the entered date of birth with the extracted document data. Exact match only. | | **Continue** | Proceeds to the next step in setting up the verification journey. | **Behavior of Fuzzy Match and Ignore Middle Names** The **Ignore Middle Names** option can be used on its own or together with **Fuzzy Match**. * When both options are enabled, fuzzy matching is applied to the first word of the first name. * Fuzzy matching continues to apply to the full last name value. **Example Scenarios** | First Name (User) | First Name (Document) | Ignore Middle Names | Fuzzy Match | Result | | ---------------------- | ----------------------- | ------------------- | ----------- | ------ | | Mike | Mike Johnson | Enabled | — | Pass | | Mike Alexander Johnson | Mikee Alexander Johnson | Enabled | Enabled | Pass | | Mike Alexander Johnson | Mikee Alexander Johnson | Enabled | Disabled | Fail | **Step 2: Configuring Face Liveness Settings** | Field | Description | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Liveness Levels** |

Determines the calibration level for liveness detection to balance convenience and security:

• Regular — Default setting. Provides acceptable security with higher user convenience.

• Soft — Reduces false rejections of genuine users while maintaining some error tolerance in detecting spoofing or presentation attacks.

• Hardened — Highest security setting. Strongly reduces spoofing risks but increases the chance of mistakenly rejecting legitimate users.

| | **Face Matching Score** | Defines the threshold for similarity between a live face and the reference image. Recommended range: **50–80%**. Adjustable using the slider. | | **Back** (button) | Navigates back to the previous step in the verification flow setup. | | **Create Verification Flow** (button) | Saves the configuration and creates the verification flow. | # Capture & Tips *** ### Overview The resolution of the image should be at least **1080p** (1920×1080 px). Smaller resolutions are accepted, but won't provide optimal results. Larger resolutions are also accepted, but won't improve the scanning process significantly. We **don't recommend going above 4k in *****any***** case**, but even 4k is not necessary for most use cases. ### Prepare Your Document

Tips

Capture clear, well-lit images of both the front and back of the ID document, ensuring all details are legible. Orient the document properly during scanning to avoid distortion or misinterpretation of data.

Positioning the document

Position the ID document so it fills 60–70% of the frame, avoiding extreme angles. Lay the document flat on a dark surface, or hold it in your hand. Do not block any data on the document.

Using lighting

Use natural lighting or a soft, even artificial light source. Avoid harsh overhead lights or direct bright lights that can cause glare or shadows. Find a location with ambient lighting.

Focusing the camera

Ensure the camera focuses on the document, avoiding blurriness. Adjust your distance from the document if necessary.

Ensuring image clarity

Ensure all four edges of the document are visible and all details, including the face (if applicable) and security features, are clear and legible. Avoid obstructions such as fingers or shadows.

Preparing the background

Keep the background clean and uncluttered to avoid distractions.

Avoiding obstructions

Ensure nothing blocks any part of the document, including the edges.

Checking document quality

In some cases, documents in poor condition (for example, peeling laminate, crumpled pages, or moisture damage) may cause the verification process to fail. Ask the customer for an additional ID or substitute document.

Visual Guidelines

The following examples illustrate the correct and incorrect application of the visual best practices outlined above.
### How to capture a Driver's License 1. Avoid glare on the document. Glare is typically from overhead lights or exterior lighting.
No Glare Document Capture
2. Do not use or accept photocopied, expired documents, or screen captures of a document.
No Photocopied & Expired Document
3. Remove all background distractions. This can be defined as objects within the camera screen for document capture, objects on the table or base where the document is positioned etc.
No Background Distraction
4. Ensure entire reverse of document is viewable and no barcodes are blocked by fingerprints or objects.
Align document within the frame
5. Do not cover the document with your fingers on or around the edges.
Do not cover the document
### How to capture Passports 1. Avoid glare on the document. Glare is typically from overhead lights or exterior lighting.
No Glare on the document
2. Do not use or accept photocopied, expired documents, or screen captures of a document.
No photocopy or expired document
3. Remove all background distractions. This can be defined as objects within the camera screen for document capture, objects on the table or base where the document is positioned, etc.
No Background distractions
4. Do not cover the document with your fingers on or around the edges.
Do not cover document
5. Move to the next or back page in the passport with additional biographical details.
Align document within the frame
# Supported Documents Identity documents and regions supported by 1Kosmos for document scanning and verification. *** ### Overview 1Kosmos can be used to scan both Identity documents (ID, DL, Passports, and so on) and Medical documents. Each document type has been issued in multiple versions throughout the years, and document design is usually significantly changed across versions. Some document changes that we have observed are: change in orientation (horizontal vs vertical), addition or replacement of the script of the document (Latin, Cyrillic, Arabic), security feature changes, and other similar updates. Key document features on supported documents are noted below (for example, document orientation and script), as well as supported document sides (front, back, bio-data page, and so on). The table below lists the supported documents for each country, along with the corresponding region. Here is the full list {% embed url="" %} {% hint style="info" %} Other than the documents listed here, 1Kosmos Recognizers also scan the **Machine Readable Zone (MRZ)** on standard (ISO/IEC 7501 compliant) **Machine Readable Travel Documents (MRTD)**. This includes **passports, visas,** and other identification documents. {% endhint %} # Release Notes *** ### 2.1.5-r.1 - September 12, 2026 #### Military ID Support in Identity Proofing Identity proofing now supports U.S. Department of Defense (DMDC) Military IDs. These documents previously failed with a "Document number is missing" error; the platform now reads the number correctly, so users can complete the proofing flow successfully. ### 2.1.3-r.1 - July 11, 2026 #### **Support for Puerto Rico Identity Cards and Driver's Licenses** Identity verification for Puerto Rico-issued Identity Cards and Driver's Licenses now completes successfully. The document extraction logic has been enhanced to combine data from both the overall document analysis and barcode/MRZ extraction, improving the accuracy and completeness of extracted document data. *** ### 2.1.0-r.3 — June 13, 2026 #### Expand Global Document Coverage for Identity Verification 1Kosmos now supports a broader range of identity documents for verification, improving coverage for global user populations. This release adds new documents and updated versions across passports, identity cards, and driver's licenses from multiple countries. **Newly Supported Documents** * Argentina — Polycarbonate Passport * Bhutan — Identity Card * Georgia — Polycarbonate Passport * Jamaica — Identity Card * Maldives — Driver's License * Mongolia — Identity Card * New Zealand — Proof of Age Card * Pakistan — Origin Card * Saint Kitts and Nevis — Polycarbonate Passport * South Sudan — Identity Card * Virgin Islands of the United States — Driver's License * Virgin Islands of the United States — Identity Card **Updated Document Versions** * Argentina, Armenia, Australia (ACT), Brunei, Bulgaria, Denmark, Georgia, Greece, Guatemala, Guyana, Kosovo, Kyrgyzstan, Liechtenstein, Mauritius, Nigeria, Puerto Rico, Uganda, USA (Passport, Montana, New York City), Venezuela. *** ### 1.13.00 — May 15, 2026 #### Support for New Identity Documents Support for additional identity documents has been added in this release. **Newly supported documents:** * USA — Veteran ID * USA, Alaska — Identity Card * USA, California — Driver's License * USA, California — Identity Card * USA, North Carolina — Driver's License * USA, Texas — Driver's License * USA, Texas — Identity Card * USA, Texas — Weapon Permit * India, Odisha — Driver's License * India, Uttarakhand — Driver's License * Nicaragua, Passport (barcode) *** ### 1.12.00.01 — January 10, 2026 #### Added Document-Format Support * Added support for Manitoba DL variations with new document number formats, 2025 Texas DL, and 2025 California DL # UX & Design Great experiences are built on three pillars: a product that looks like yours, works for everyone, and speaks your customers' language. This section explains how {{Product}} supports each of these. *** ### What's in this section * Brand Customization - Make 1Kosmos match your brand, from logo and colors to text and content. * Accessibility - How 1Kosmos is built to conform to WCAG 2.2 Level AA so your experience is usable by everyone. * Localization - Deliver 1Kosmos in your customers' preferred language, region, and formats. ### Our design principles * **Consistency by default, flexibility where it matters.** Sensible defaults out of the box, with the controls to tailor what your brand needs. * **Accessible from the ground up.** Accessibility is a baseline, not an add-on. * **Inclusive at global scale.** Built for multiple languages, locales, and writing directions. # Branding Customization 1Kosmos can be styled to reflect your brand so that, to your customers, it feels like a seamless extension of your own product. This page covers everything you can customize and how to apply it. *** ### What you can customize
Highlighting components which can be customized to reflects customers identity
| Element | Customizable | Notes | | --------------------------------- | ------------ | ---------------------------------------------- | | Logo | ✅ | Light and dark variants | | Primary color | ✅ | Used for primary buttons, links, active states | | Secondary color | ✅ | Used for secondary actions, accents | | Text / content color | ✅ | Body and heading text | | Background color | ✅ | — | | Typography / fonts | ✅ | — | | Content & copy (labels, messages) | ✅ | — | ### Logo Upload your logo to replace the default 1Kosmos branding across the interface. **Recommended specifications:** * **Formats:** SVG (preferred for crispness at any size), PNG with transparent background * **Dimensions:** recommended max height 40px in the header * **File size:** under 1 MB ### Colors Set your brand palette to carry your identity through every screen. * **Primary color** — Your main brand color. Applied to: primary buttons, links, selected states, progress indicators. * **Secondary color** — A complementary color for :secondary buttons, highlights. * **Text color** — The color of body and heading text. {% hint style="info" %} Custom colors must maintain sufficient contrast against their backgrounds (WCAG 2.2 AA requires a contrast ratio of at least **4.5:1** for normal text and **3:1** for large text and UI components. {% endhint %} ### Content & text Beyond visual styling, you can tailor the words your customers see. * **Custom labels and copy** * **Custom links** * **Email / notification templates** ### Best practices * Provide both light and dark logo variants for a polished result in every theme. * Test your palette against the built-in contrast checker before publishing. * Keep copy concise and consistent with the rest of your product's voice. * Preview changes before publishing to all users. # Responsive Design 1Kosmos is built to work across the full range of screen sizes your customers use — from large desktop monitors to phones. The interface reflows automatically so content stays readable. ***
Identity Verification is inclusive of all screen sizes
### Supported screen sizes 1Kosmos adapts across three broad layout ranges: | Layout | Typical devices | Width range | | ------- | ----------------- | ----------- | | Desktop | Laptops, monitors | ≥ 1024px | | Tablet | iPads, tablets | 768–1023px | | Mobile | Phones | < 768px | ### What changes across screen sizes As the screen narrows, the layout adapts rather than simply shrinking: * **Layout & content** — Multi-column layouts reflow into a single column so nothing requires horizontal scrolling. * **Touch targets** — On touch devices, interactive controls are sized for fingers rather than a cursor, meeting accessibility minimums [(see Accessibility)](/identity-verification/ux-and-design/accessibility). * **Images & logos** — Your brand assets scale to fit; this is why we recommend an SVG logo [(see Brand Customization).](/identity-verification/ux-and-design/branding-customization) ### Best practices * Preview your branding on both desktop and mobile before publishing — a logo that looks right in the header can crowd a narrow screen. * Keep custom copy concise so it reads well on small screens. * Test interactions on a real touch device, not just a resized browser window. # Accessibility We believe great products should be usable by everyone, regardless of ability. 1kosmos is designed and built to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. *** ### What WCAG 2.2 AA means WCAG 2.2 (a W3C Recommendation since October 2023) organizes accessibility requirements around four principles: content must be **Perceivable, Operable, Understandable, and Robust**. Level AA is the conformance level most widely adopted by organizations and referenced by regulations such as the ADA (US), Section 508, and the European Accessibility Act / EN 301 549. WCAG 2.2 builds on 2.1 with additional success criteria, including improvements for focus visibility, touch target sizes, dragging alternatives, consistent help, and more accessible authentication. ### Finding your way around: the command palette Every page in AdminX is reachable from the keyboard using the command palette, a global search available from the header. **To open it:** * Click **Search** in the top-right of the header, or * Press **⌘K** (Mac) / **Ctrl+K** (Windows) Start typing to filter across top-level pages, including Dashboard, Directory, Users, Applications, Authentication, Reports, Settings, Verification, and Workflows. Use the arrow keys and **Enter** to jump to a result without touching the mouse. Your search history is retained for 7 days. ### Accessibility improvements | Where | What changed | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Session Details | A Copy to clipboard button next to the session data view lets you copy details without a mouse, and is reachable by keyboard shortcut. | | Session Events | Keyboard navigation now moves focus through events in the correct order. | | Sidebar icon tooltips | Tooltips stay visible on hover and can be dismissed, instead of disappearing as the pointer moves onto them. | | Sidebar expand control | Announced by screen readers within the navigation region, in the correct reading order. | | Verification Flows / Templates | New default ID proofing templates apply automatically to all tenants. A new Edit template option is available directly on the Verification Flows page. | | Forms, analytics, calendar, pagination | Form fields are labeled, charts are operable using a keyboard, and selected states meet color contrast minimums. | | Share via text | A new Country Code label was added alongside the phone number field. | | Document scan and selfie capture screens | Updated to a clean white background across templates, replacing the previous green gradient and dark capture screen. Visual update only; no change to the capture flow. | ### How we support accessibility * **Keyboard navigation** — All interactive elements are reachable and operable using a keyboard alone. * **Command palette** — A keyboard-first **Search** control in the AdminX header opens a command palette. Type to find any top-level page in the console and go straight to it, without navigating through menus. * **Screen reader support** — Semantic markup and ARIA labels provide a meaningful experience with assistive technologies such as NVDA, JAWS, and VoiceOver. Focus order follows the logical structure of each page, including navigation regions and controls such as the sidebar expand control. * **Color contrast** — Default themes meet the 4.5:1 (text) and 3:1 (large text / UI) contrast minimums, and our branding tools help you preserve contrast in custom themes. * **Visible focus indicators** — A clear focus state shows keyboard users where they are as they move through forms, tables, charts, and the ID proofing capture flow. * **Persistent, dismissible tooltips** — Tooltips on sidebar icons and other controls remain visible on hover and can be dismissed, instead of disappearing as the pointer moves onto them. * **Accessible forms, charts, and data views** — Form fields carry proper labels, charts are operable using a keyboard, and selected states across tables, calendars, and pagination controls meet color contrast minimums. * **Responsive layout** — The header, navigation, verification screens, forms, analytics, calendar, pagination, and the ID proofing capture flow adapt responsively across screen sizes. # Localization 1Kosmos can be delivered in your customers' preferred language and regional formats, so the experience feels native wherever they are. *** ### Supported languages Identity Verification is currently available in four languages: | Language | Code | Status | | -------- | ---- | --------- | | English | `en` | ✅ Default | | Spanish | `es` | ✅ | | French | `fr` | ✅ | | Chinese | `zh` | ✅ | ### Setting the language * **Automatic detection** - 1Kosmos detects the user's preferred language from their browser settings / account profile and displays the matching translation when available. * **Manual selection** - Users can change their language from the dropdown Regional formatting ### Customizing translations If you'd like to adjust wording or add terminology specific to your brand, you can. # Verification Sessions Continuously monitor every identity verification session — spot risky attempts instantly, filter by outcome and signals, and trace a person's full verification history at a glance. ### Overview Previously, identity verification activity review meant working with a fixed set of columns and session-level results only, with no way to filter by risk-oriented criteria or see a single person's history across multiple attempts. A new **Sessions (BETA)** page has been introduced under Verification of the AdminX interface with a customizable table, richer filtering and search, and a new way to view activity grouped by user rather than by individual session. {% hint style="info" %} The Sessions page includes nine optional filters and 14 customizable columns to display in the results table. {% endhint %}
The **Sessions** page lets you: * Analyze verification activity across sessions — outcomes, risk levels, detected signals, and locations. * Investigate a single person's history across multiple attempts. * Customize which columns appear, filter, and search to focus on the sessions that matter. * Switch between viewing every session and viewing activity grouped by user. #### Navigation In AdminX, go to **Verification → Sessions**. By default, the page shows the **All Sessions** view for **Today**, with 25 sessions per page. ### What actions community administrators can perform * [#switch-between-all-sessions-and-unique-users](#switch-between-all-sessions-and-unique-users "mention") * [#customize-the-table-columns](#customize-the-table-columns "mention") * [#filter-sessions](#filter-sessions "mention") * [#search](#search "mention") * [#sort-and-view-time-period](#sort-and-view-time-period "mention") * [#view-session-details](#view-session-details "mention") #### Switch between All Sessions and Unique Users Use the **All Sessions / Unique Users** toggle above the table: * **All Sessions** (default) shows every individual verification session as its own row. If a person completes five sessions, it appears as five rows. * **Unique Users** groups all of a person's sessions into a single row. A unique user is identified by First Name + Last Name + Date of Birth, so sessions from the same person are combined.
In the Unique Users view, each row summarizes the user's attempts — for example, "8 Attempts, 1 failed · 7 passed" — along with their risk level and signals detected. Expanding a row shows the user's sessions, 5 per page, up to the 10 most recent, sorted latest first. #### Customize the table columns Click **Edit Table View** to choose which columns appear. * Checked columns are shown; unchecked columns are hidden. * Some core columns (such as Identity) are always present and cannot be removed. * Some columns are available only for specific view types. * Click **Apply** to update the table, or **Cancel** to close without changes. * **Reset to Default** restores the default columns; it is available only after you have changed the layout.
When you show many columns, the table scrolls horizontally while the Identity and Actions columns stay in place. Columns always appear in their defined order regardless of the order you select them. #### Filter sessions Use the filters to narrow the sessions shown. Only filters for columns that are currently visible are offered, and filters apply as soon as they are selected. * **Journey** — multi-select and searchable; filter across one or more verification journeys. * **Failure reasons** — IDV failure codes shown as readable reasons, grouped into categories (for example, Document Authenticity & Liveness, Biometric / Selfie Verification). Selecting multiple reasons returns sessions containing any of them. * **Document Type** — searchable, multi-select, grouped into Physical Documents and Electronic IDs; only document types enabled for your tenant are shown. * **Outcome** — All, Passed, Failed, Not Performed, or Review. * **Status** — All, In Progress, Pending, Abandoned, Expired, Declined, or Completed (shown when the Status column is visible). * **Risk** — All, Low, Medium, or High. * **Signals** — the five supported risk signals in this phase; multi-select.
Active filters appear as chips. When there are many, the list scrolls and shows a "+N" indicator you can hover to see the full list. Filters apply consistently to both All Sessions and Unique Users — the page first finds the matching sessions, then groups them in the Unique Users view, so the aggregates reflect the current filters and time period. #### Search Use the search field to find sessions by Session ID or by a user's first and last name. Any filters you have applied stay active while you search. #### Sort and view time period * **Sort by** — Latest or Risk Level. * **Time period** — Today, This Week, 1 Month, or Select dates for a custom range. #### View session details Select a session's **View Details** action to open its Session Detail view on a separate page. # Verification Analytics ### Overview Verification Analytics is currently released as a beta feature. The Verification Analytics page shows how identity verification is performing across your verification journeys — how many people verify successfully, where they fail, how often they retry, and how long verification takes. It replaces the previous Analytics page and adds specific failure-reason reporting, so you can see which checks are driving failures and act on them. You can analyze results at two levels — Unique Users and All Sessions — filter by journey and time period, and review four areas: * key indicators * verification performance over time * top failure reasons * risk signal breakdown All metrics on the page are calculated using completed sessions only. A completed session is one that reached a final outcome — Success, Failed, or Not Performed — so sessions a user abandoned partway through are not counted.
#### Navigation In AdminX, go to **Verification → Verification Analytics**. By default, the page shows **All Verification Journeys** for **This week**. Metrics are shown in your local time zone (displayed at the top of the page). #### Filtering the data | Filter | Options | | ----------------------------------- | ----------------------------------------------------------------------------- | | Filter by Verification Journey Type | All Verification Journeys, a specific journey, or a select number of Journeys | | Time period | Today, This Week, This Month, or a custom date range (Select dates) | The filters apply to the whole page. #### Choosing Unique Users or All Sessions Metrics can be viewed by **Unique Users** or **All Sessions**, selected from the **Showing metrics for** control. A unique user is identified by **First Name + Last Name + Date of Birth**, so multiple sessions from the same person count as one user, while the session total still reflects every session. {% hint style="warning" %} The **Key Indicators** section and the **Verification Performance Over Time** graph each have independent selectors. Changing one does not affect the other. {% endhint %} ### Key indicators The top tiles summarize verification performance for the selected journey and period. | Indicator | What it shows | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Total Completed Sessions | The number of completed sessions, or unique users, in scope based on the selected view. In the Unique Users view the subtext shows how many completed sessions those users represent. | | Verification Success Rate | Percentage of completed sessions that were completed successfully | | Successfully Verified | Percentage of completed sessions that were completed successfully | | Failed Verification | Number that failed, with change from the prior period | | First-Attempt Success Rate | Percentage of successful verifications completed on the first attempt. | | Retry Rate | Percentage of completed sessions that required one or more retries. | | Face Liveness Failure Rate | Percentage of completed sessions that failed the face liveness check, out of all completed sessions where the check was performed. | | Avg. Verification Time | Average time to complete verification | {% hint style="info" %} * All indicators are calculated on completed sessions only. * First-Attempt Success Rate and Retry Rate are always calculated at the unique-user level, even in the All Sessions view, because they require grouping a user's sessions. {% endhint %} ### Verification performance over time The **Verification Performance Over Time** graph plots verification results across the selected period. Depending on the selected view, it shows total, successful (passed), failed, and incomplete users or sessions, so you can see trends and improvement over time. ### Top failure reasons The **Top Failure Reasons** chart lists the top 10 reasons verifications failed for the selected journey and period. Each reason shows: * the number of sessions in which that failure occurred, and * its weight, that reason's share of all failure occurrences. {% hint style="info" %} A single session can fail more than one check, so it contributes to each failure reason it contains. As a result, the weight is calculated against the total occurrences of all failure reasons, not the number of failed sessions. {% endhint %} ### Risk signal breakdown The **Risk Signal Breakdown** lists the risk signals detected for the selected journey and period, alongside the number of users affected by each. Risk signals indicate potential fraud or identity manipulation that falls outside standard document and face verification checks. They point admins to patterns worth investigating rather than failures tied to a single session. Each entry shows: * the risk signal name, * a short description of what it detects, and * the number of users affected. Risk signals currently reported include: | Risk signal | What it detects | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Different Face Detected for the Same User | A different face is detected across verification sessions associated with the same identity (first name, last name, and date of birth) | | Geolocation Change Between Sessions | The same identity (first name, last name, and date of birth) is verified from a location more than 500 miles away from a previous session | | Virtual Camera Detected | Potential use of virtual or manipulated camera sources during verification | | Document & IP Country Mismatch | The issuing country of the presented document differs from the user's IP geolocation country | | Identity Mismatch With Authoritative Source | The extracted identity (first name, last name, and date of birth) does not match the authoritative identity on file | {% hint style="info" %} **Notes** * Each signal shows the number of users affected for the selected journey and period. * This page replaces the previous Analytics page. * All metrics are calculated on completed sessions only — a completed session is one with a final result of Success, Failed, or Not Performed. Abandoned/incomplete sessions are excluded, and the trend graph no longer shows an "Incomplete" series. * The page opens with the Unique Users view and the This Week period by default. * Unique-user identity is based on First Name + Last Name + Date of Birth. * Failure reasons identify the specific verification/fraud check that failed and are derived from IDV error codes. {% endhint %} # Risk Signals ### Overview Passing standard identity verification checks (document authenticity, face match, and liveness) does not, by itself, rule out fraud. A session can pass those checks and still show risky attributes or behavior, such as using a virtual camera during the selfie, a document whose issuing country doesn't match the useris connection locationa virtual camera used during the selfie, a document whose issuing country doesn't match where the user is connecting from, or the same identity appearing with different faces across attempts. A risk signal flags one of these risky attributes or behaviors for administrator review. Signals are evaluated at the end of a verification session and reported for review. {% hint style="info" %} **Phase 1 is report-only.** Detected signals are informational: they are surfaced for administrator review and do not automatically change, delay, or block the verification outcome. {% endhint %} Each session carries an overall Risk Level and a count of Signals Detected, which appear on the Sessions page so you can see and investigate why a session looks risky. #### Navigation In AdminX, go to **Verification → Risk Signals**. The page lists all supported signals, with a short description of what each detects, plus a summary of how many are enabled and how many fall into each risk level.
### Configuring a signal For each signal in the list, you can: * **Enable or disable it** using the toggle. Only enabled signals are evaluated and reported. * **Set its risk level** to Low, Medium, or High using the Risk Level dropdown. {% hint style="warning" %} Changes take effect when you save. They apply to sessions created after the change is saved. In-progress sessions keep the configuration they started with, and completed sessions are not re-evaluated. {% endhint %} ### Available signals | Signal | What it detects | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Document & IP Country Mismatch | The issuing country of the presented document differs from the user's IP geolocation country | | Different User Detected on Same ID | The same face is seen across verification sessions under a different identity (name/DOB) | | Geolocation Change Between Sessions | The same identity (first name, last name, DOB) verifies from a location more than 500 miles from any of its recent prior sessions | | Identity Mismatch With Authoritative Source | The extracted identity (first name, last name, DOB) does not match the authoritative identity on file | | Virtual Camera Detected | A virtual or manipulated camera source is used during verification | Signals fall into two kinds: * **Session-level signals** are determined from the current session alone, for example, Virtual Camera Detected and Document & IP Country Mismatch. * **Cross-session signals** are determined by comparing the session against the same user's other attempts, for example, different User Detected on Same ID and Geolocation Change Between Sessions. ### How is the overall risk level determined? Each detected signal contributes to the risk level you configured for it. When a session detects more than one signal, the session's overall Risk Level is the highest level among the detected signals. Multiple signals at the same level don't raise it further; for example, two Low signals still result in an overall Low risk level. ### Reviewing signals on the Sessions page On the Sessions page, each session shows its **Risk Level** and its **Signals Detected** count. Open a session to see the individual signals that were detected, so you can understand why it received its risk level and decide how to act. # Overview *** Database verification cross-checks the data captured during identity proofing against **authoritative and third-party record sources** - issuing authorities, government registries, and identity-data providers. Instead of judging a document by its appearance alone, the platform asks the systems of record whether the identity actually exists and whether the submitted details match. It is a passive, back-end check: in most cases the user does nothing beyond the capture they have already completed. The result is a strong corroboration signal that complements document authentication and biometric matching. ### Why It Matters Document scanning and liveness confirm that a *real, unaltered document* is being presented by a *live person*. Database verification answers a different question: **does this identity exist in an authoritative source, and does the submitted data match the record on file?** A document can be genuine in appearance yet not correspond to any valid record - or it can be a real document tied to a different person. Checking against the source of record closes that gap and raises overall assurance. ### Methods Covered | Method | Question it answers | User friction | | ------------------------------ | ----------------------------------------------------------------------------------------------------- | ------------------- | | **AAMVA Verification** | Do US driver's licenses and state IDs match the issuing state's DMV record? | None (passive) | | **Aadhaar Verification** | Does the Aadhaar number correspond to a valid record, and do the holder's details match? | Low (consent / OTP) | | **Person Search Verification** | Do aggregated identity records corroborate the name, address, and other attributes the user provided? | None (passive) | {% hint style="info" %} Database checks are configured per verification flow. Coverage varies by document type, country, and source availability — confirm which sources are enabled for your tenant before relying on a given check. {% endhint %} ### Combining Database Checks Database verification is most powerful in combination. A document scan with face match establishes that a real person holds a real document; layering AAMVA, Aadhaar, or person search on top confirms that the underlying identity is recognized by authoritative and independent sources. Higher-assurance flows generally enable one or more database checks as required steps, while lower-risk flows may run them as advisory signals or omit them entirely. # AAMVA Verification *** ### Overview For US driver's licenses and state-issued ID cards, the platform cross-checks the data extracted from the scan against the issuing state's authoritative records through the **American Association of Motor Vehicle Administrators (AAMVA)** network. This validates the license against the actual DMV record rather than against an expected document appearance. #### What Gets Checked When a US driver's license or state ID is scanned, the extracted attributes are matched against the DMV record for that license number. The response indicates whether: * The license number **exists** in the issuing state's records * The **name** on the scan matches the DMV record * The **date of birth** matches * The **issue date** matches * The **expiry date** matches * The license is currently **valid** (not suspended, revoked, or canceled) A mismatch on any field - or a "no record found" response - produces a granular reason code that downstream systems can act on. #### What It Does and Doesn't Tell You * **It confirms** that the license corresponds to a real DMV record and that the submitted details match that record. * **It does not confirm** that the person presenting the document is its rightful holder - the biometric and liveness checks provide that binding. * **Coverage varies by state.** Not every state participates in every check, and some return an inconclusive result rather than a definitive match or non-match. Treat these per your risk model. # Person Search Verification *** ### Overview Person search verification corroborates the identity attributes a user provides - such as **name, address, and date of birth** - against **aggregated identity records** drawn from public and commercial data sources. Rather than checking a single document against a single issuer, it looks for consistent evidence that the claimed identity exists and is associated with the details provided. #### What Gets Checked A person search typically evaluates whether the submitted attributes are **corroborated** across one or more record sources. Common signals include: * Whether the **name and address** appear together in established records * Whether the **date of birth** is consistent with those records * Whether the combination of attributes resolves to a **single, coherent identity** rather than conflicting or non-existent records The check returns a corroboration outcome - for example, a match, a partial match, or no match - that can be used on its own or combined with other database checks to raise assurance. #### What It Does and Doesn't Tell You * **It confirms** that the claimed identity is corroborated by independent records and is consistent across sources. * **It does not authenticate** the person in real time, and it is not a sanctions, watchlist, or credit screen - pair it with the appropriate dedicated checks where those are required. * **Coverage and data depth vary** by region and by the attributes supplied. Sparser records may return a partial or inconclusive result for legitimate users. {% hint style="info" %} Person search is best used as a **corroborating** signal alongside document and biometric verification, not as a standalone proof of identity. {% endhint %} # Aadhaar Verification via DigiLocker *** ### Overview For users in India, the platform can confirm that the holder's demographic details, such as name and date of birth, match the record held against their Aadhaar number, the identity number issued by the national identity authority. The **Aadhaar Verification (DigiLocker)** node runs this check via DigiLocker, the Government of India's document wallet. You add the node to a workflow in the Workflow Builder and branch the flow on the result. The node matches the name, date of birth, and PIN code the user provides, together with a LiveID selfie, against the user's DigiLocker record, and returns a pass/fail decision with individual match scores. ### What Gets Checked The node confirms: * That the name, date of birth, and PIN code the user enters match the record held against their Aadhaar number * That the face captured in the user's LiveID selfie matches the record, with a liveness check to confirm a live user is present * That the user consented to the DigiLocker lookup and completed it with a one-time password (OTP) ### What It Does and Doesn't Tell You It confirms that the user's submitted details and selfie correspond to the Aadhaar record held by DigiLocker, with individual match scores for name, date of birth, PIN code, and face. It does not verify the Aadhaar number in isolation. The check runs through DigiLocker, so it depends on the user completing DigiLocker sign-in or sign-up and giving consent; if the user cannot access DigiLocker, the node cannot complete the verification. ### Prerequisites * Community Administrator access to the AdminX UI and the Workflow Builder. * The Aadhaar Verification (DigiLocker) node enabled for your tenant. If you don't see it in the Node Library, contact your 1Kosmos representative. ### Add the Node to a Workflow 1. Open the Workflow Builder. 2. In the Node Library on the right, expand the **Third-Party Verification** category. 3. Locate **Aadhaar Verification (DigiLocker)** and drag the node onto the canvas. 4. Connect the node's branches to the rest of the workflow. 5. Click **Save**. Use **Preview** to review the flow before publishing. ### End User Experience
When the workflow reaches this node, the end user: 1. Enters their full name (as per Aadhaar), date of birth, and PIN code, then selects **Verify with DigiLocker.**
![](https://691395313-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjgyVKgYJP0xNjsiKAcPm%2Fuploads%2FKovQOv87Y772TMZrgRTP%2FAadhaar1.png?alt=media\&token=70d5e791-67a5-4252-92fa-987daa6f0265)
2. Captures a LiveID selfie to complete the liveness check. 3. Is redirected to the DigiLocker portal to authenticate. 4. Enters their Aadhaar number, verifies the OTP sent to their registered mobile number, and enters their 6-digit DigiLocker security PIN.\ \ ![](https://691395313-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjgyVKgYJP0xNjsiKAcPm%2Fuploads%2FQuz8QnnhUjdFbYgSStRY%2FAadhaar2.png?alt=media\&token=344900e4-7c26-4924-875f-50314ac7f780) 5. Reviews the requested Aadhaar information and selects **Allow** to provide consent for sharing. 6. Is redirected back after DigiLocker processes the request. 7. Sees a confirmation once their identity has been successfully verified. {% hint style="info" %} DigiLocker delivers the result through a callback after the user gives consent, so expect a short delay between consent and the workflow advancing. {% endhint %} ### Viewing Aadhaar Verification Results In addition to the node's own output, community administrators can review a readable summary of any Aadhaar verification attempt from the Sessions page in AdminX. 1. Go to **Verification > Sessions**. 2. Find the session for the user you want to review. Each row shows the identity, document type (**Aadhaar Card**), outcome (**Passed** or **Failed**), risk level, signals detected, and location. 3. Click the session to open **View Results**. The View Results page shows: * **Session Details** — Session ID, session status, the browser/OS used, and the IP address the session was run from. * **Summary** — the user's name, the document type, and the **Overall Recommendation** (**Verification Passed** or **Verification Failed**). * **Match Score** — See [#match-score](#match-score "mention") * **Data Extracted** — the name, date of birth, country, and PIN/zip code read from the Aadhaar record. * **Images** — captured images for the session, available on request via **Show Images**.
#### Match Score The Match Score panel breaks the overall recommendation down into the four individual checks that feed it: * **Full Name Match** — whether the name the user entered matches the name on the Aadhaar record. * **Face Match** — whether the LiveID selfie matches the record, shown as **Match** or **No Match** alongside a confidence score (for example, 0.98). This is the only field in the panel that displays a numeric score; the other three show only a match/no-match badge.\ The default face match threshold is set to 0.7; A `face_match_confidence` score above 0.7 is accepted, and this threshold is not configurable by users or admins today. * **DOB Match** — whether the date of birth the user entered matches the record. * **Address Match** — whether the PIN code the user entered matches the record. This corresponds to the `zip_match_confidence` field in the node's own response. Each of the four checks is evaluated independently, so a session can show **Verification Failed** overall while some fields still show **Match** (for example, a face mismatch does not affect the Full Name, DOB, or Address results). Use this panel together with the individual match fields when you need to know which specific check caused a failure, rather than relying on the overall recommendation alone. This is the same Match Score and recommendation data returned in the node's own response, presented for administrators to review without needing to inspect raw node output. # Overview *** ## Non-Document Verification Non-document verification establishes a user's identity using authoritative data sources and possession signals - without asking them to capture a passport, driver's license, or ID card. Instead of extracting attributes from a document image, the platform queries trusted issuers, government registries, credit bureaus, mobile network operators, or national eID schemes to confirm the user is who they claim to be. These methods exist because document capture isn't always the right tool. For many use cases - re-verification of an existing customer, low-friction onboarding for thin-file users, regulated markets where a national eID is the de facto standard, or recovery flows where a user no longer has their original document - non-document verification is faster, cheaper, and just as defensible. ### What's in this section
eIDVerify through a national or bank-issued electronic identity scheme (eIDAS, BankID, itsme, and similar)eID Verification
SSN verificationValidate a US Social Security Number against authoritative sources and confirm name/DOB binding.SSN Verification
Phone-based verificationUse carrier intelligence and possession checks to confirm identity through the user's mobile number.Phone-Based Verification
### How non-document methods differ from document verification | | Document verification | Non-document verification | | ----------------------- | ----------------------------------------------- | -------------------------------------------------------------------------- | | User effort | Capture document + selfie | Enter a few fields or authenticate with an existing credential | | Median time to complete | 1–3 minutes | 10–45 seconds | | Source of truth | The physical document and its security features | Authoritative database, issuer, or trusted attribute provider | | Coverage | Anyone with a supported document | Depends on data availability in the user's country/region | | Typical assurance | Up to IAL2 with biometric binding | Varies by method — eID can reach IAL2; SSN/phone alone are typically lower | | Best for | First-time onboarding, regulated KYC | Re-verification, thin checks, account recovery, regional fit | ### When to choose a non-document method Non-document verification is the right fit when: * **Friction matters more than maximum assurance.** A high-converting onboarding flow that completes in 20 seconds is more valuable than a 3-minute document scan that 30% of users abandon. * **You have a strong attribute to anchor on.** A US SSN, an EU eID, or a mobile number tied to a long-tenured carrier account are all anchors strong enough to verify against without a document. * **The user has already been document-verified before.** Re-verification at session, transaction, or compliance refresh time rarely needs the full document flow again. * **The market expects it.** In the Nordics, BankID is the verification method. Asking for a driver's license scan there is unusual and feels off-brand. Match the market. * **You're recovering an account.** The user has lost access — making them produce a document they may not have anymore is the wrong default. A non-document path with appropriate fraud signals is usually better. ### When to stick with document verification Reach for document verification when: * You're opening a new account under a regulated KYC/AML regime that mandates documentary evidence. * The user has no usable identity attribute on file (no SSN, no eID, no consistent phone history). * You need IAL2 or IAL3 assurance and the user doesn't have an eID at the required level. * The transaction risk justifies the friction (high-value money movement, irreversible actions). See [Verification methods ](/identity-verification/verification-methods)for the full document-based catalog. ### Combining methods Non-document and document verification are not mutually exclusive. Common patterns: * **Document first, non-document for re-verification.** A user verifies their passport on signup; six months later, a phone-based possession check is enough to confirm it's still them before a high-risk action. * **Non-document first, document for step-up.** A user opens a basic account with an SSN check, then completes document verification only when they want to enable a feature that requires higher assurance. * **Parallel signals.** Run a phone-based fraud check in the background while the user completes a document scan, and fail the verification if the two diverge. The right composition depends on your risk model. Most teams converge on a tiered approach where the verification rigor scales with what the user is trying to do. # eID Verification Verify identity using a government-issued or bank-issued electronic ID scheme *** ## Overview An electronic ID (eID) is a digital identity credential issued by a government, regulated bank consortium, or accredited identity provider. Examples include eIDAS-notified schemes across the EU, BankID in Sweden and Norway, MitID in Denmark, itsme in Belgium, iDIN in the Netherlands, FranceConnect in France, and similar schemes in other regions. Where these exist, they're typically the most trusted, lowest-friction way to verify identity — the user already has the credential, the issuer has already done the heavy identity proofing, and the assurance level is government-defined. eID verification reuses that existing credential rather than re-proofing the user from scratch. ### What happens during eID verification {% stepper %} {% step %} **The user picks their eID provider** If your verification flow supports multiple eID schemes (common in cross-border deployments), the user selects which one they want to use. Otherwise the flow goes straight to the configured provider. {% endstep %} {% step %} **The user authenticates with the eID** The user is redirected to their eID provider — their bank app, the national identity portal, a mobile eID app, or a smart-card reader, depending on the scheme. They authenticate using whatever the scheme requires: a PIN, biometric, hardware token, or push approval on a registered device. Verification never sees the user's eID credentials directly. The eID provider does the authentication and returns a signed assertion. {% endstep %} {% step %} **The eID provider returns verified attributes** After successful authentication, the eID provider sends back a set of verified attributes — typically name, date of birth, a national identifier, and optionally address. These attributes carry the assurance level of the eID scheme itself. {% endstep %} {% step %} **Attributes are validated and stored** The verification service checks the signature on the assertion, confirms the assurance level meets the flow's requirement, and persists the verified attributes alongside the verification result. The user can then continue with whatever the original transaction was. {% endstep %} {% endstepper %} ### What you get back A successful eID verification produces: * **Verified identity attributes** — name, date of birth, and other fields the scheme exposes (varies by provider and what the user consents to share). * **A national or scheme-specific identifier** — for example, a Swedish personal identity number from BankID, or a Belgian national register number from itsme. Treat this as highly sensitive PII. * **Assurance level** — the scheme's stated level, mappable to NIST IAL or eIDAS Substantial/High. * **A signed assertion** — the cryptographic proof the verification actually came from the issuer. Retain this for audit. For the wrapping result schema, see [Verification result](/identity-verification/core-concepts/viewing-verification-results). ### Why this method works well | Benefit | What it means in practice | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Very low friction** | The user authenticates with a credential they already have and use frequently. Median completion times are 10–30 seconds. | | **High assurance out of the box** | Most eID schemes are issued at substantial or high assurance — equivalent to or stronger than document + selfie verification. | | **Regulator-recognized** | In the EU, eIDAS-notified eIDs are accepted by member states for KYC under AMLD. In the Nordics, BankID is the de facto standard for financial onboarding. | | **Reduced fraud surface** | The user never types attributes manually, so typos, mismatches, and synthetic identity injection at data entry are eliminated. | | **Inclusive of users without travel documents** | Many citizens have an eID but not a passport. Supporting eID broadens your verifiable population. | ### Use cases where eID is the right default * **Financial onboarding in markets with strong eID adoption.** In Sweden, Norway, Denmark, Belgium, the Netherlands, Estonia, and similar markets, your users will expect to see their eID as the primary option. * **Cross-border KYC under eIDAS.** A user in one EU member state can verify into a service in another using their notified eID. * **Re-verification and step-up.** A user who originally onboarded with a document can step up to a sensitive action using their eID — fast for the user, cryptographically strong for you. * **Recurring compliance refresh.** Annual or biennial re-KYC where you just need fresh evidence the user is still who they were. * **Public sector and healthcare.** Government services and health platforms in countries with national eIDs almost universally use them as the primary verification method. # SSN Verification Validate a US Social Security Number against authoritative data sources without requiring a physical SSN card. *** ## Overview SSN verification confirms that a US Social Security Number is valid, that it's associated with the user claiming it, and — depending on the data source — that the user's name, date of birth, and other identity attributes match the official record. It happens entirely from data the user provides; no SSN card scan is required. This makes it one of the lowest-friction verification methods available for US users. The trade-off is that SSN verification on its own is a lighter check than document + selfie — it confirms the SSN is real and belongs to the claimed individual, but it doesn't physically prove the person sitting at the device is that individual. Pair it with another signal (biometric, possession, or document) when assurance matters. ### What happens during SSN verification {% stepper %} {% step %} **The user enters their identity attributes** At minimum, the user provides their SSN, full legal name, and date of birth. Some flows also collect address. Inputs are masked client-side and transmitted over TLS to the verification service. {% endstep %} {% step %} **The SSN is structurally validated** Before any external lookup, the SSN is checked against known structural rules — valid area numbers, no known invalid ranges (such as the famous 078-05-1120 once printed on a sample card), and length/format. Obvious bad inputs are rejected immediately without burning a downstream lookup. {% endstep %} {% step %} **The SSN is verified against an authoritative source** The platform queries one of: * **eCBSV (Electronic Consent Based SSN Verification)** — the Social Security Administration's authoritative consent-based service. Returns a simple yes/no on whether the submitted SSN, name, and DOB match SSA records. * **Credit bureau attribute matching** — queries one or more of the major US credit bureaus (Equifax, Experian, TransUnion) for an identity record matching the submitted attributes. Returns a match score plus optional supplementary fields. * **Issuance and death indicators** — checks whether the SSN was issued before the claimed date of birth (a synthetic-identity signal) and whether it appears on the SSA Death Master File. The choice of source depends on the flow's configuration and the use case's regulatory requirements. {% endstep %} {% step %} **Result is returned** The verification returns a pass/fail decision plus the specific signals that informed it — match score, issuance check, death indicator, and any data-source-specific flags. If the result is inconclusive (common with thin-file users), the flow can route to a fallback verification method or to manual review. {% endstep %} {% endstepper %} ### Why this method works well | Benefit | What it means in practice | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Extremely low friction** | A few text fields and 5–10 seconds to complete. No camera, no document, no upload. | | **Strong synthetic-identity detection** | Issuance-date and death-indicator checks catch a meaningful fraction of synthetic and stolen identities — failures document verification alone wouldn't detect. | | **Authoritative for US KYC** | eCBSV is SSA's own service; credit bureau matching is the basis of decades of KYC and CIP programs. Regulators understand and accept these. | | **Works for thin-document users** | Users without a passport or current driver's license can still verify if they're in the credit-bureau or SSA record. | | **Cheap to run as a fraud signal** | Even when document verification is the primary method, running an SSN check in parallel adds a useful independent signal at low cost. | ### Use cases where SSN verification fits * **Lightweight customer onboarding for US-only services.** Low-risk accounts (free tiers, content platforms, marketplace seller signup) where document verification would be over-collection. * **Customer Identification Program (CIP) under the USA PATRIOT Act.** Where rules allow non-documentary CIP, SSN verification is a foundational component. * **Re-verification at sensitive moments.** Confirm an existing user's SSN before allowing a tax-document download, a wire transfer, or a beneficiary change. * **Composite KYC.** Combine SSN verification with phone-based verification and a credit-bureau header match for a layered, document-free KYC that meets CIP requirements at very low friction. # Phone-Based Verification Verify identity using mobile carrier intelligence and possession checks on the user's phone number. *** ## Overview Phone-based verification uses the user's mobile number as a verification anchor — confirming both **possession** (the user can receive a signal at that number) and **identity attributes** (the number has been associated with the claimed person, with stable tenure, and isn't a recent SIM-swap or port-out target). It produces a verification result without any document scan, and on most mobile devices it completes in under 30 seconds. The method is particularly powerful because the data sources — mobile network operators — already perform their own identity proofing when issuing SIM cards in most regulated markets. Reusing that signal at verification time is efficient and effective. ### Two layers of signal Phone verification combines two distinct types of check: | Layer | What it confirms | How | | ------------------------------------ | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Possession** | The user is in control of the phone number right now. | One-time passcode via SMS, voice call, or silent network authentication. | | **Attribute / carrier intelligence** | The phone number is associated with the claimed person and isn't a fraud risk. | Queries against MNO records: name and address match, line type (postpaid/prepaid/VoIP), account tenure, recent SIM swap or port-out activity. | A robust phone-based flow uses both. Possession alone proves the user has a phone; attribute checks prove it's their phone. ### What happens during phone-based verification {% stepper %} {% step %} **The user enters their mobile number** Captured with country code, normalized to E.164 format. Obvious invalid formats are rejected client-side before any lookup. {% endstep %} {% step %} **Carrier intelligence checks run** The platform queries one or more upstream data providers for: * **Subscriber attributes** — name and address on the carrier account, to match against what the user claims. * **Line type** — distinguishes postpaid contracts (highest trust), prepaid (medium), VoIP and burner numbers (low trust, often rejected outright). * **Tenure** — how long the number has been continuously held by the same subscriber. Long tenure is a strong positive signal; sub-30-day tenure is a synthetic-identity red flag. * **Recent SIM swap activity** — was the SIM card associated with this number recently re-issued? Recent swaps are a leading indicator of account takeover. * **Recent port-out activity** — was the number recently moved between carriers? Often correlates with takeover attempts. {% endstep %} {% step %} **Possession is verified** Depending on the device and the flow's configuration, one of: * **SMS one-time passcode** — universal but vulnerable to SIM-swap and SS7 attacks; suitable for low-to-medium assurance. * **Silent mobile network authentication** — on mobile data, the device authenticates directly with the carrier's network without an OTP at all. The user doesn't see or type anything; the flow just confirms the number is the one connected on the cellular link. This is the strongest and lowest-friction option where supported. {% endstep %} {% step %} **Result is returned** Pass/fail decision plus the per-check signals: attribute match score, line type, tenure days, SIM swap indicator, possession method used. {% endstep %} {% endstepper %} ### Why this method works well | Benefit | What it means in practice | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Lowest friction in the catalog** | With silent network authentication, the user doesn't type anything — the verification happens transparently. With OTP, it's a single short code. | | **Universal coverage in mobile-first markets** | Nearly every adult in any developed market has a mobile number. No document, no eID, no SSN required. | | **Strong fraud signals built in** | SIM swap and port-out detection are leading indicators of account takeover. Getting these signals at verification time is high-leverage. | | **Useful as a continuous signal** | Phone-based checks can run on every login or every high-risk action, not just at onboarding. | | **Reusable for re-authentication** | A user who verified with their phone at onboarding can re-authenticate via the same channel without re-doing the whole flow. | ### Use cases where phone-based verification fits * **Account recovery.** A user has lost access to their email or credentials. A phone-based verification — especially with attribute matching against the original onboarding data — is a defensible recovery path that doesn't require dragging the user through a full re-verification. * **Step-up before sensitive actions.** Money movement, beneficiary changes, password resets — quick possession + SIM-swap check before allowing the action. * **Low-friction onboarding for digital products.** Subscription apps, marketplaces, and consumer services that don't need full KYC but want a fraud-resistant signup gate. * **Composite KYC.** Phone-based verification as one of multiple non-documentary CIP signals (alongside SSN and credit-bureau header match) for US regulated onboarding. * **Continuous fraud monitoring.** Background SIM-swap monitoring on the user's number, surfacing alerts when a swap is detected so you can pre-emptively step up authentication. * **Markets where document capture is unreliable.** Regions with high mobile penetration but mixed document quality benefit from phone-first verification. ### Configuration considerations | Decision | Notes | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Possession method | Silent network authentication where available (mobile data), with SMS as fallback. Voice call for accessibility and landline support. | | Retry policy | Cap OTP retries at 3 to limit brute force. Lock the number out for a cool-down period after consecutive failures. | | Combination with other methods | Phone-based verification is most valuable as part of a composite. Define the role explicitly: primary verification, fraud signal, possession-only, or step-up. | ### Standards and regulatory context * **NIST SP 800-63B** treats SMS as a restricted authenticator and recommends against it for new high-assurance deployments. Silent network authentication and out-of-band push approval rank higher. * **PSD2 Strong Customer Authentication (EU)** accepts possession factors including device-bound mobile authentication; SMS OTP is allowed but increasingly considered weak. * **FFIEC guidance (US banking)** explicitly calls out the risks of SMS OTP and recommends layered authentication that includes device intelligence and behavioural signals. Phone-based verification done well combines possession, attribute matching, and risk signals into a single check. Done poorly — SMS OTP alone, with no carrier intelligence — it's a checkbox that fraudsters routinely defeat. The difference is in the configuration. # Overview Non-document fraud signals that assess identity risk from an IP address, email address, and phone number — adding a passive, low-friction layer to document and biometric verification. *** Document and biometric verification confirm that a person holds a genuine identity document and matches it. Fraud prevention signals answer a different question: **does the surrounding context look legitimate?** These checks analyze the digital attributes a person presents during onboarding or authentication — their IP address, email address, and phone number — to estimate risk before, during, or alongside document verification. Because they run on data the user already provides, these checks are typically **passive and low-friction**: they add little or no extra effort for legitimate users while surfacing risk that a document scan alone cannot detect, such as synthetic identities, location spoofing, or account-takeover attempts. {% hint style="info" %} These are non-document checks. They complement — rather than replace — document and biometric verification, and are most effective when combined as part of a layered (defense-in-depth) approach. {% endhint %} ### How non-document signals fit into a verification journey Non-document signals are commonly used in three ways: * **Pre-checks** — Run early in a journey to filter out obvious fraud (for example, a disposable email or a datacenter IP) before spending time and cost on document capture. * **Risk scoring** — Combined into an overall risk assessment that informs an allow, deny, or manual-review decision. * **Step-up triggers** — When a signal looks risky, the journey can require additional verification (such as document capture or biometrics) instead of failing outright. ### The signals covered in this section [ IP Geolocation ](/identity-verification/fraud-prevention/ip-geolocation) [Email Intelligence ](/identity-verification/fraud-prevention/email-intelligence) [Phone Intelligence ](/identity-verification/fraud-prevention/phone-intelligence) ### Why a layered approach matters No single signal is conclusive on its own — a VoIP phone number or a VPN connection is not proof of fraud, and many legitimate users have both. The value comes from **correlation**: when several signals disagree with each other or with the identity being claimed (for example, an IP in one country, a phone number registered in another, and a recently created email with no history), confidence in the risk assessment rises. Layering these signals reduces both fraud losses and false rejections of genuine users. # IP Geolocation Assess risk from a user's IP address — approximate location, network type, and anonymizer use — to detect location spoofing, high-risk geographies, and suspicious access patterns. *** ### Overview IP geolocation derives an approximate physical location and network profile from the IP address a user connects from. During onboarding or authentication, it provides immediate context about *where* and *how* a user is connecting — without asking them for anything. {% hint style="info" %} IP geolocation is an estimate, not a precise position. Accuracy is typically strong at the country level and decreases for region and city. Treat it as a risk signal, not a definitive location. {% endhint %} ### What the check analyzes When a user connects, the IP address is evaluated for attributes such as: * **Geographic location** — Country, region, and city associated with the IP. * **Network and ownership** — The internet service provider (ISP) and the autonomous system (ASN) that owns the address space. * **Connection type** — Whether the IP belongs to a residential network, a mobile carrier, or a hosting/datacenter provider. * **Anonymizer use** — Whether the connection is routed through a VPN, proxy, or the Tor network. ### Risk signals it surfaces | Signal | What it may indicate | | --------------------------------- | -------------------------------------------------------------------------------------------------- | | Connection via VPN, proxy, or Tor | The user may be hiding or misrepresenting their true location. | | Datacenter or hosting-provider IP | Traffic may be automated (bots/scripts) rather than a real person on a consumer device. | | Location mismatch | The IP country conflicts with the document country, phone country, or stated address. | | High-risk or sanctioned geography | The connection originates from a region the organization restricts or watches closely. | | Impossible travel | The same account connects from distant locations in a span of time too short to physically travel. | ### Benefits and use cases * **Onboarding fraud detection** — Flag applicants who mask their location or connect from infrastructure rather than a personal device, a common pattern in synthetic-identity and bulk-account fraud. * **Account-takeover (ATO) prevention** — Detect logins from unexpected countries or anonymizing networks and trigger step-up authentication. * **Geographic and regulatory controls** — Restrict access from embargoed or out-of-scope regions to support compliance obligations. * **Reducing friction for genuine users** — A consistent, residential IP that matches the rest of the identity can support a faster, lower-friction path. * **Promotion and bonus-abuse prevention** — Identify many accounts originating from the same network or anonymizer, a hallmark of incentive abuse. ### Where it fits in the journey Because it requires no user input, IP geolocation is well suited to running **at the very start of a journey** as a pre-check, and **continuously at each authentication** to watch for changes in connection behavior over time. # Email Intelligence Assess risk from a user's email address — domain validity, disposable-address detection, age, and online footprint — to spot fake and synthetic identities during onboarding. *** ### Overview Email intelligence evaluates an email address to gauge how likely it is to belong to a real, established person rather than a throwaway or fabricated identity. An email address is one of the first attributes a user provides, which makes it a valuable early signal. {% hint style="info" %} A low-reputation email is a risk indicator, not proof of fraud. Legitimate users sometimes use new or privacy-focused addresses, so email signals work best combined with other checks. {% endhint %} ### What the check analyzes The email address is evaluated for attributes such as: * **Validity and deliverability** — Whether the domain exists, has valid mail (MX) records, and can plausibly receive mail. * **Disposable or temporary address detection** — Whether the domain provides short-lived, throwaway inboxes commonly used to evade tracking. * **Domain type and age** — Whether the domain is free webmail, corporate, or custom, and how long it has existed. * **Online footprint** — Whether the address is associated with established accounts and activity across the web. * **Breach exposure and history** — Whether the address has appeared in known data breaches or has prior history, which can indicate a real, aged identity. ### Risk signals it surfaces | Signal | What it may indicate | | -------------------------------- | ------------------------------------------------------------------------ | | Disposable or temporary domain | The user wants to remain untraceable or create a one-time account. | | Recently registered domain | The address may have been created solely to pass this check. | | No online footprint | The address has no history consistent with a real, active person. | | Invalid or undeliverable address | The contact point is unusable, blocking later verification and recovery. | | Mismatch with the claimed name | The address content is inconsistent with the identity being presented. | ### Benefits and use cases * **Synthetic-identity detection** — Fabricated identities often rely on freshly created or disposable email addresses with no real-world history. * **Fake-account and spam prevention** — Block bulk sign-ups that depend on throwaway inboxes. * **Cleaner contact data** — Ensuring an address is valid and deliverable protects later steps that depend on email, such as one-time passcodes and account recovery. * **Lower friction for trusted users** — An established, well-reputed address can support a faster onboarding path. * **Earlier, cheaper fraud filtering** — Catching bad signups before document capture reduces verification cost and reviewer workload. ### Where it fits in the journey Email intelligence is typically applied **as soon as the address is collected**, often before document verification, so high-risk applicants can be filtered, challenged, or routed to manual review early. # Phone Intelligence Assess risk from a user's phone number — line type, carrier, portability, and SIM-swap signals — to prevent OTP interception, account takeover, and synthetic identities. *** ## Phone Intelligence Phone intelligence evaluates a phone number to determine whether it is valid, what kind of line it is, and whether it shows signs of being used for fraud. Because phone numbers are widely used for one-time passcodes (OTPs) and account recovery, their trustworthiness has a direct impact on security. {% hint style="info" %} As with the other signals, no single phone attribute proves fraud. A VoIP number or a recent port is a risk indicator to weigh alongside the rest of the identity. {% endhint %} ### What the check analyzes The phone number is evaluated for attributes such as: * **Validity and format** — Whether the number is correctly formatted and active for the claimed country. * **Line type** — Whether it is a mobile, landline, VoIP, or virtual/prepaid number. * **Carrier and country** — The mobile carrier and the country the number is registered to. * **Portability and recent porting** — Whether the number has recently been moved between carriers. * **SIM-swap indicators** — Whether the SIM associated with the number was changed recently (subject to carrier data availability). * **Identity linkage** — Whether the number is associated with the name or identity being presented. ### Risk signals it surfaces | Signal | What it may indicate | | --------------------------------- | ------------------------------------------------------------------------------------------- | | VoIP or virtual number | The number is cheap and disposable, common in fraud and harder to tie to a real person. | | Recent SIM swap | An attacker may have hijacked the number to intercept OTPs — a key account-takeover vector. | | Recently ported number | Ownership may have changed; recovery and OTP delivery may be compromised. | | Number not linked to the identity | The phone does not match the person being claimed. | | Invalid or unreachable number | The contact point cannot reliably receive verification messages. | ### Benefits and use cases * **OTP and account-takeover protection** — Detecting a recent SIM swap before sending an SMS OTP helps prevent passcode interception, one of the most damaging ATO techniques. * **Smarter delivery decisions** — When a number is VoIP or unreachable, the journey can choose a more secure factor instead of relying on SMS. * **Synthetic-identity detection** — Fabricated identities frequently use virtual or prepaid numbers with no genuine ownership history. * **Fake-account prevention** — Block bulk registrations that depend on disposable numbers. * **Lower friction for trusted users** — A long-held mobile number that matches the identity supports a faster, more confident verification. ### Where it fits in the journey Phone intelligence is valuable **before sending any OTP or relying on the number for recovery**, and during step-up authentication when a number-based factor is about to be used. # Overview *** Identity Assurance Levels (IALs) are a set of standards defined by the National Institute of Standards and Technology (NIST) that convey the degree of confidence that someone's claimed identity is their real identity — in other words, how likely an individual is actually who they say they are. The three identity assurance levels, as defined in [NIST Special Publication 800-63](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf), are: | Level | Description | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **IAL1** | No requirement to link the individual to a specific real-life identity. Any information provided by the individual should be treated as self-asserted. | | **IAL2** | Uses digital documents to support the real-world existence of an identity and verifies that the correct person is associated with it. | | **IAL3** | Requires an authorized and trained representative to verify the individual in person. | Users can upgrade their own status to IAL2 in AdminX by using the 1Kosmos web-based identity-proofing flow. Tenant and community administrators can trigger this flow using OpenID Connect (OIDC) ACR claims or SAML. ### Automated Ways to Get to IAL2 1Kosmos follows guidelines from [NIST SP 800-63A](https://pages.nist.gov/800-63-3/sp800-63a.html) for remote identity proofing, attempting to strike a pragmatic balance between availability and convenient access to identity-proofing services and the security of the associated processes. Several combinations of evidence quality are accepted at IAL2: * **One piece of SUPERIOR or STRONG evidence** (depending on the strength of original proof and validation with the issuing source), or * **Two pieces of STRONG evidence**, or * **One piece of STRONG evidence plus two pieces of FAIR evidence** | Type of Evidence | Strength | Notes | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | US Passport | SUPERIOR | Includes US Passport cards | | Foreign e-Passport | SUPERIOR | | | Personal Identity Verification (PIV) card | SUPERIOR | | | Common Access Card (CAC) | SUPERIOR | | | Personal Identity Verification Interoperable (PIV-I) card | SUPERIOR | | | Transportation Worker Identification Credential (TWIC) | SUPERIOR | | | Permanent Resident Card | SUPERIOR | Issued on or after May 11, 2010 | | Native American Enhanced Tribal Card | SUPERIOR | | | REAL ID cards | STRONG+ | Includes REAL ID driver's licenses and ID cards. REAL ID cards have a star printed in the upper right-hand corner. Card and personal information must be validated with the appropriate DMV or AAMVA. | | Enhanced ID cards | STRONG+ | Includes Enhanced ID driver's licenses and ID cards. Must be validated with the appropriate DMV or AAMVA. | | U.S. Uniformed Services Privilege and Identification Card (U.S. Military ID) | STRONG+ | Includes Uniformed Services Dependent ID Cards. Must be validated with the appropriate military issuing source. | | Permanent Resident Card | STRONG | Issued prior to May 11, 2010 | | Native American Tribal Photo Identification Card | STRONG | | | Driver's License or ID card (REAL ID non-compliant) | STRONG | | | School ID card | FAIR | Includes facial image photograph | | Utility account statement | FAIR | | | Credit/debit card and account statement | FAIR | | | Financial institution account statement | FAIR | | | US Social Security Card | WEAK | | | Original or certified copy of a birth certificate issued by a state, county, municipal authority, or outlying possession of the United States bearing an official seal | WEAK | | 1Kosmos provides journeys that allow users to get to IAL2 depending on the evidence collected from them. ### In This Section * **IAL2 Verification** — Create and manage a one-time IAL2 verification flow. * **One-Time Verification** — The end-to-end one-time identity verification journey. * **Triggering IAL2 Verification Using OAuth 2.0 and OIDC** — Trigger step-up verification with custom scopes and ACR claims. * **Triggering IAL2 Verification Using SAML** — Trigger verification using `RequestedAuthnContext`. * **Identity Wallet Based Verification** — Reuse previously verified identities stored in the user's wallet. # Create & Manage IAL2 Verification Administrators can create and manage a new Identity Assurance Level 2 (IAL2) verification flow. This feature enables end users to complete a one-time IAL2 verification. *** ### Overview Community administrators can create and manage a new Identity Assurance Level 2 (IAL2) verification flow. This feature enables end users to complete a one-time IAL2 verification by submitting two specified identity documents, a biometric, and an SSN. Unlike the standard verification workflow, this process does not retain verified user information after verification. It supports compliance and assurance requirements that require one-time verification without data persistence. ### Key Capabilities | Capability | Description | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **Custom Document Requirements** | Define any two types of identity documents that users must submit during the verification process. | | **Session Expiration Control** | Set an expiration interval for verification sessions. By default, sessions expire after 30 minutes if not completed. | | **UI Customization** | Modify the user interface to align with specific IAL2 workflow requirements. | | **Data Retention Settings** | Configure how long verified user data is retained, based on compliance or business needs. | | **Flow Deployment** | Save and deploy configured flows for immediate use by end users. | This feature enables a one-time, persistent verification process, distinguishing it from the existing flow where user data may be deleted or reset. {% hint style="info" %} For the end-to-end verification journey — prerequisites, triggering the flow, and the step-by-step identity verification experience — see **One-Time Verification**. {% endhint %} # One-Time Verification The one-time IAL2 verification flow enables end users to verify their identity by submitting two specified identity documents, a biometric, and an SSN. *** {% hint style="info" %} This process does not retain verified user information after verification. {% endhint %} ### Prerequisites for Identity Verification Before you begin verifying your identity, ensure the following: * **Camera Access** — Make sure your device's camera has the necessary permissions enabled. * **Selfie Check Tips** — Avoid glare in the background and remove any hats, glasses, or masks for a clear facial capture. * **Document Preparation** — Have your identity documents ready before starting the verification process. ### Triggering the IAL2 Journey Community administrators can use the following API to generate a verification URL and send the link to the user via email or phone: ``` /workflowapi/workflow_instance/tenant/{tenantId}/community/{communityId}/create ``` ### Verifying Identity End users can use the generated session URL to begin identity verification. Ensure you have the appropriate identity document ready for scanning and submission. 1. Click the session URL you received. 2. Read the instructions on the **Getting Started** screen and click **Start Verification**. 3. Grant the necessary camera permissions; click **Allow Camera Permissions**. On the **Allow Camera Permission** screen, the UI checks whether the device camera meets the required resolution of 1080×1920. If the requirement is not met, the UI redirects to the **QR Scan** screen, prompting the user to scan a QR code to continue the verification process on another device. 4. On the **Selfie Check** screen, click **Begin Selfie**. 5. Position your face within the oval shown on the screen. When aligned properly, click **Take Selfie**. 6. After successfully capturing your selfie, prepare the required identity documents as displayed on the screen, then click **Continue** to proceed. 7. Read the instructions on the **Scan the Document** screen carefully, then click **Scan Document** to proceed. 8. Scan the front side of the first document. Once its authenticity is verified, the system prompts you to scan the next required document; click **Continue**. If the authenticity check fails, a **Verification not performed** message appears. Click **Try Again** to repeat the process. 9. As an additional verification step, you are prompted to enter your Social Security Number (SSN). Enter the SSN and click **Continue** to proceed. Upon successful verification, the UI confirms that your identity has been successfully verified and displays a list of the documents used during the verification process. # OAuth 2.0 and OIDC *** ## Triggering IAL2 Verification Using OAuth 2.0 and OIDC Users can upgrade their own status to IAL2 in AdminX by using the 1Kosmos web-based identity-proofing flow. Tenant and community administrators can trigger this flow using OpenID Connect (OIDC) ACR claims. ### Prerequisites * A configured OIDC application in AdminX. Before starting, ensure you have configured an OIDC application for SSO. See[ OIDC Integration in AdminX](broken://spaces/HOTUyFysR7VGBxLPNQgq/pages/OrNxj40Mvau8KV8HLlB1) for more information. To view your OIDC application settings: 1. Navigate to your AdminX portal and log in as a tenant or community administrator. 2. Go to the **Applications** page and find your OIDC application. 3. Click the pencil icon under **Actions** to view the OIDC application settings. Your **Client ID** and **Client Secret** can be viewed and copied from this screen. ### Fetch Current IAL Using Custom Scope Your current IAL can be requested using the **`/assurance/ial/2`** custom scope, as shown below: ``` https://blockid-trial.1kosmos.net/oauth2/community/default/v1/authorize ?response_type=code &client_id=ae0456c92ac24f0ace200f103ab93c81 &scope=email openid /assurance/ial/2 &redirect_uri=https://google.com &state=123 ``` The OIDC response returned by the server contains the user's current IAL, located in the `amr` parameter. ### Requesting IAL2 Step-Up Verification #### Using Custom Scope IAL2 step-up verification can be requested using the **`/assurance/ial/2`** custom scope in your request, as shown below: ``` https://blockid-trial.1kosmos.net/oauth2/community/default/v1/authorize ?response_type=code &client_id=ae0456c92ac24f0ace200f103ab000000 &scope=openid /assurance/ial/2 &redirect_uri=https://google.com &state=123 ``` Response payload: ```json { "sub": "1PJ8RjLctvisMZvADuKNp", "ial": "IAL2", "acr": "/assurance/ial/2/", "amr": [ "IAL2" ], "at_hash": "zYYYvMoJBs9v4kOhiyt000", "aud": "33724c7d05e452695658af5a38500000", "exp": 1680079821, "iat": 1680076221, "iss": "https://blockid-trial.1kosmos.net/oauth2/community/default" } ``` From a user's standpoint, they are redirected to AdminX to perform their step-up identity verification instead of a standard login. Once the identity verification is completed, the user is at IAL2. #### Using ACR Claims IAL2 step-up verification can also be requested using **ACR Claims**, as shown below: ``` ?response=... &client_id=... &scope=... &redirect_uri=... &state=... &claims={ "id_token": { "acr": { "values": ["/assurance/ial/2/"] } } } ``` From a user's standpoint, they are redirected to AdminX to perform their identity verification instead of a standard login. Once the identity verification is completed, the user is at IAL2. ### OIDC Responses Depending on the user's current IAL level after performing their identity verification, the server returns different responses. The table below shows the OIDC responses returned after a user has attempted an identity verification. | Requested AuthnContext | User's IAL Level After Identity Verification | OIDC Response | | ---------------------- | --------------------------------------------------------------- | -------------------------------------------------------- | | IAL2 | IAL1 (Failed Identity Verification or Insufficient Information) | `{ "acr": "/assurance/ial/2/", "amr": [] }` | | IAL2 | IAL2 | `{ "acr": "/assurance/ial/2/", "amr": ["IAL2"] }` | | IAL2 | IAL3 | `{ "acr": "/assurance/ial/2/", "amr": ["IAL2","IAL3"] }` | # SAML *** ## Triggering IAL2 Verification Using SAML Users can upgrade their own status to IAL2 in AdminX by using the 1Kosmos web-based identity-proofing flow. Tenant and community administrators can trigger this flow using SAML. ### Prerequisites Before starting, ensure you have integrated your Service Provider (SP) for SSO as a SAML application. See **SSO Integration in AdminX** for more information on configuring your Service Provider (SP) in AdminX. ### Configuring Your Service Provider (SP) in AdminX 1. Navigate to your AdminX control panel and log in as a community or tenant administrator. 2. Go to the **Applications** page and find your SAML application. Click the pencil icon under **Actions** to edit the SAML application settings. 3. Click **Next** to view the SAML settings for your application. 4. Under **Claims Mapping**, click **Add new**. 5. Select `ial` from the drop-down menu under **BLOCKID LEDGER ATTRIBUTES**. 6. Enter a format to use with the attribute and click **Create**. Administrators can optionally map an identity attribute to use with this SAML claim, such as the user's first or last name as shown on their driver's license or passport. 7. Click **Add new** once more to add another claims mapping. 8. Find the **identity attribute** you wish to add, such as `dl.lastname`, and assign a format. 9. Click **Create** to save. 10. Click **Next** once you have finished mapping all your SAML claims. 11. Click **Save** to complete the IAL claims mapping for your SAML application. ### Requesting IAL2 Verification as a Service Provider Once the SAML attributes have been mapped in AdminX, Service Providers can request IAL2 verification using `RequestedAuthnContext` as part of the SAML request. When the branded claim is received by the IdP (1Kosmos), it triggers an IAL2 journey to elevate the user's identity assurance level. ```xml urn:oasis:names:tc:SAML:2.0:ac:classes:IAL2 ``` From a user's standpoint, they are redirected to AdminX to perform their identity verification instead of a standard login. ### SAML Responses Depending on the user's current IAL level after performing their identity verification, the server returns different responses. The table below shows the SAML responses returned after a user has attempted an identity verification. These responses can be viewed using a SAML tracer if desired. | Requested AuthnContext | User's IAL Level After Identity Verification | SAML Response | | ---------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | IAL2 | IAL1 (Failed Identity Verification or Insufficient Information) | `` | | IAL2 | IAL2 | `urn:oasis:names:tc:SAML:2.0:ac:classes:IAL2` | | IAL2 | IAL3 | `urn:oasis:names:tc:SAML:2.0:ac:classes:IAL2urn:oasis:names:tc:SAML:2.0:ac:classes:IAL3` | # Identity Wallet-Based Verification Identity wallets allow you to store identity documents, and social security details, all in one place on your smartphone or on the web. They allow you to reuse previously verified identities. *** ### Identity Wallets on the Smartphone Every time you download and install the 1Kosmos app, a new identity wallet is created for you using public key cryptography. A decentralized identifier along with the key pair constitute your identity wallet. PII information about the user is stored within the wallet and requires the user's private key and biometrics to read data from the wallet. The private key is securely stored in the Secure Enclave of the device, and the public key is stored by relying parties. When data from the wallet needs to be presented to a relying party, the holder must present biometrics and consent to share data. When approved, the private key is presented as a credential to unlock the wallet and share data. The private key never leaves the device, minimizing it from compromise. ### Identity Wallets for the Web For enterprises looking to onboard their customers purely from a web-based journey, 1Kosmos supports web wallets that are implicitly created during sign-up. A decentralized identifier along with the public key and private key constitute your identity wallet. Web wallets are protected by password-based or passwordless MFA methods. In addition, wallets require a user-provided PIN to unlock the wallet. ### Replacing Passwords with Public Key Cryptography Public key cryptography reduces the threat from potential database breaches. Initiating 1Kosmos mobile generates a public-private key pair on the user's authenticator (a physical device). The user's public key is stored by requesting websites / relying parties, but this alone is useless to an attacker. An attacker cannot derive the user's private key from the data stored on the server, which is required to complete authentication. # Overview *** ### Fundamentals of Verifiable Credentials A credential is any document that details a qualification, competence, or authority issued to an individual by a third party with the relevant authority to do so. Because credentials are typically issued by authorities that hold the public's trust, they are often used to support proof of an individual's qualification or competence for a given subject. #### Credentials in the Real World In the physical world, a credential might consist of: * Information identifying the **subject** of the credential (for example, a photo, name, or identification number) * Information related to the issuing authority (for example, a city government, national agency, or certification body) * Information related to the type of credential (for example, a Dutch passport, an American driving license, or a health insurance card) * Information related to specific attributes or properties being asserted by the issuing authority about the subject (for example, nationality, the classes of vehicle entitled to drive, or date of birth) * Evidence related to how the credential was derived * Information related to constraints on the credential (for example, expiration date or terms of use) A **verifiable credential** can represent all of the same information that a physical credential represents. The addition of technologies such as digital signatures makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. #### Why Are Verifiable Credentials Needed? It is currently difficult to express education qualifications, healthcare data, financial account details, and other third-party verified, machine-readable personal information on the Web. This difficulty makes it challenging to receive the same benefits through the Web that physical credentials provide in the physical world. The VC specification provides a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. #### An Emerging Standard Verifiable credentials allow for the digital proofing of user claims data through public-private cryptography, privacy-preserving, and semantic disambiguation techniques. The **VCs Data Model**, defined at the [W3C](https://www.w3.org/), is a universal data format that lets any entity express anything about another entity. It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy respecting, and machine-verifiable. A common standardized data model enables standardized credential packaging, cryptographic signing, and proof expression, creating a VC ecosystem with interoperable credentials that can be processed and understood across disparate systems. #### Ecosystem Overview The key actors in an ecosystem where verifiable credentials are used: | Role | Description | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Holder** | A role an entity performs by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers. | | **Issuer** | A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting it to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. | | **Subject** | An entity about which claims are made. Example subjects include human beings, animals, and things. In many cases the holder of a verifiable credential is the subject, but not always — for example, a parent (the holder) might hold the verifiable credentials of a child (the subject). | | **Verifier** | A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include employers, security personnel, and websites. | | **Verifiable Data Registry** | A role a system performs by mediating the creation and verification of identifiers, keys, and other relevant data — such as verifiable credential schemas, revocation registries, and issuer public keys. Examples include trusted databases, decentralized databases, government ID databases, and distributed ledgers. | #### Issuing and Verifying Credentials There are four roles supported by verifiable credentials — **Issuer**, **Verifier**, **Subject**, and **Holder**: * **Issuer** — The entity that creates a claim and associates it with a particular subject. * **Verifier** — The entity verifying a claim about a given subject. * **Subject** — The entity about whom a claim is issued. * **Holder** — A role an entity may perform by possessing one or more verifiable credentials. A holder is usually, but not always, the subject of the verifiable credentials they hold. Holders store their credentials in credential repositories. #### Tasks Users of verifiable credentials have common needs across domains. Examples of tasks that issuing authorities, holders, and verifiers might perform include: * Issuing a claim * Asserting a claim * Verifying a claim * Storing or moving a claim * Retrieving a claim * Revoking a claim *** ### Verifiable Credentials Use Cases #### Multi-Domain Use Case Map Use cases for verifiable credentials can span several key domains: * Education * Retail * Finance * Healthcare * Professional Credentials * Legal Identity * Devices #### Finance **Reuse KYC and Anti-Money Laundering** Consider the following scenario: a woman wishes to open an account at a bank, and as part of that process the bank asks her to provide two sources of ID to confirm her identity — the "Know Your Customer" (KYC) check. She selects government-supplied verifiable credentials to ensure she receives mail at a specific address where she has a national ID card. These government-issued documents help the bank confirm her identity, and an account is opened for her. The bank then issues her a digitally-signed credential for her account. This credential verifies that the user: 1. Has an account at the bank and sufficient permission to access the account. 2. Has completed a KYC check. Furthermore, the issued credential may also be used as sufficient verification by other financial institutions. It assures other banks that the user is verified, alleviating concerns about misdirected transactions and money laundering. **Money Transfer** A user with a bank account at one financial institution wants to send funds to his family in another country via a money transfer service. He has verifiable credentials in his credential repository that can be used to share his identity profile, as well as a credential from his family verifying the destination bank account. By sharing these verified credentials with the money transfer service, both the source and the destination of funds can be verified. This adds confidence to the delivery of the funds and meets the regulatory requirements to prevent money laundering. #### Education In this scenario, the VC issuer is an educational institution that issues a VC representing the completion of degree requirements to graduating students. The institution decides what information should be packaged in the credential, and attributes will have values expressed. **Student Requesting a Digital Transcript** A university issuing an "extended transcript" that includes course grades could, upon the request of students, issue a digital credential representing the degree awarded to the student. Examples of what might be in such a credential: * First Name * Last Name * Degree Type * Date of Issue **Student Transferring Claims from School to Bank** Students in schools that offer a credential repository service to all students and alumni could use another entity — such as a bank offering a similar service — to move their claims to the service provided by the bank, without needing to have them reissued by the school. *** ### Verifiable Credentials Data Model #### Zero-Knowledge Proof A Zero-Knowledge Proof is a method of authentication that, through the use of cryptography, allows one entity to prove to another that they know certain information or meet a specific requirement without disclosing any of the factual information that supports that proof. The entity that verifies the proof has "zero knowledge" about the data supporting the proof but is "convinced" of its validity. This is especially useful where the prover entity does not trust the verifying entity but still has to prove that it knows specific information. #### Derived Credentials and Credential Presentations A derived credential is an assertion about the value of another attribute (or set of attributes) in a verifiable credential. Derived credentials are valuable in zero-knowledge-proof-style verifiable presentations because they can limit information disclosure. For example, suppose a verifiable credential contains an attribute expressing a specific height in centimeters. A derived predicate might reference the height attribute in the verifiable credential, demonstrating that the issuer attests to a height value meeting the minimum height requirement — without actually disclosing the specific height value (for example, the subject is taller than 5 feet). A subset of one or more verifiable credentials can make up the presentation. #### Metadata Cryptographically signed by the issuer. As described in the W3C standard [Verifiable Credentials Data Model v1.1](https://www.w3.org/TR/vc-data-model/), metadata "describes properties of the credential, such as the issuer, the expiry date and time, a representative image, a public key to use for verification purposes, the revocation mechanism, and so on." #### Claims A statement made about a subject. Example: *"John Doe's date of birth is 01/01/1990."* #### Proofs A proof is data about yourself (the identity holder) that allows others to verify the source of the data (the issuer), check that the data belongs to you and only you, confirm that the data has not been tampered with, and finally confirm that the issuer has not revoked the data. *** ### 1Kosmos's Implementation of Verifiable Credentials #### Lifecycle * Issuers issue credentials to users. * Users are holders of a verifiable credential. * Holders may present the verifiable credential to an entity. * The entity may request verification of the presented credential. * The verifier confirms the validity of the presented credential with the requesting entity. #### Issuance Portal The order of operations remains the same even if 1Kosmos issues the credential on behalf of the issuing authority. #### Verification Portal 1Kosmos provides a verification portal to confirm the validity of presented credentials. # Setting Up Microsoft Verified ID Integration
Adding Verifiable Credentials to Microsoft Authenticator once verified with 1Kosmos
This section outlines the end-to-end process for setting up and testing a Verified ID issuance and verification flow using **Microsoft Entra Verified ID**. It covers: * Configuring the verification journey * Deploying a sample VerifiedID application * Testing credential issuance * Provisioning Verifiable Credentials (VCs) into the Microsoft Authenticator app #### Issuance Flow Overview The Issuance Flow of Verified ID is categorized into two phases — the **Configuration** phase and the **Issuance** phase. * **Configuration phase** — Administrative setup activities such as configuring the 1Kosmos app within Entra, retrieving the Client ID and Client Secret, and configuring the ID proofing flow. * **Verified ID Issuance phase** — The end user performs the identity verification process by submitting their identity documents and selfie, and scans the QR code to provision the generated Verifiable Credential (VC) into the Microsoft Authenticator app. **Configuration phase** To set up the Verified ID issuance process, the administrator performs the following configuration steps in Entra and 1Kosmos: 1. Configure the 1Kosmos app in the Entra portal. 2. Retrieve the Client ID and Client Secret from Entra for the 1Kosmos application. 3. Define the ID proofing flow within the 1Kosmos platform. 4. Use the 1Kosmos **Verification Flows** page in the AdminX interface to create and manage verification journeys. 5. Complete the Entra integration setup to enable secure communication between Entra and 1Kosmos. **Verified ID Issuance phase** To complete the Verified ID issuance, the user performs the following steps to verify identity and receive the Verifiable Credential: 1. Enter your username to initiate the proofing process. 2. Enter the one-time password (OTP) sent for authentication. 3. In the generated proofing session, submit the required identity documents. 4. Provide a selfie for verification. 5. After successful verification, 1Kosmos generates a Verifiable Credential (VC) and retrieves the credential link from Entra. 6. Scan the displayed QR code using the Microsoft Authenticator to receive the Verifiable Credential. The Verified ID is securely stored in the user's digital wallet. #### Step 1: Configuring the Verification Journey Use the 1Kosmos **Verification Flows** page in the AdminX interface to create and manage verification journeys. Two types of journey are supported — select a journey and create a verification flow for users: * **KYC with Selfie** — Users are prompted to scan an identity document and then capture a selfie for comparison. * **Document Verification Only** — Enables standalone document verification without any selfie or liveness check. For more information, see [Configuring Verification Flows.](/identity-verification/configurations) #### Step 2: Configuring Sample VerifiedID Application Settings This section provides the steps to deploy the sample VerifiedID application and configure it with the required permissions. 1. Reach out to your 1Kosmos representative to deploy the sample VerifiedID application. 2. Follow the [Microsoft documentation ](broken://pages/BvUtXkDnVR2PcCC5klBO)to set up an application with the appropriate permissions. 3. Provide the Client ID and Client Secret to 1Kosmos to configure the sample app. 4. Once configured, you will be able to test the generation of Entra VerifiedID. #### Step 3: Testing Generated Entra VerifiedID {% hint style="info" %} **Prerequisites** — Ensure users exist in the 1Kosmos user directory with the following fields: First Name, Last Name, Phone Number, Email, and Date of Birth (optional). {% endhint %} 1. Navigate to the Sample App. 2. Enter your email address. 3. Choose the type of document and the device you will use for verification. 4. You will receive a link to continue the process. 5. Follow the instructions under the **Verifying Identity** section to complete document verification. 6. After successful verification, you will be presented with an option to generate a VerifiedID. #### Step 4: Provisioning VCs into Your Microsoft Authenticator App 1. Scan the QR code using the Microsoft Authenticator app. 2. Once the scan is successful, the verified ID is added to your wallet. 3. You can now request your end user to share their Verified Credential with you by sending a Presentation Request through Microsoft Entra. # 1Kosmos Interoperability with Verifiable Credentials Platforms *** **Verifiable Credentials (VC)** are a standardized data model with a secure expression protocol that many industries and contexts can use to issue and verify credentials. Credentials created for one narrow purpose can be used for another at the discretion of their holder or subject, requiring no technical federation to the originating issuers. The 1Kosmos implementation of the verifiable credentials specification conforms to this fundamental premise and is a highly interoperable implementation. #### Azure ION Azure ION is a Layer 2 permissionless network based on the purely deterministic *Sidetree* protocol, which requires no special tokens, trusted validators, or additional consensus mechanisms. #### 1Kosmos Verifiable Credentials Samples **Sample VC Attestation Template** ```json { "attestations":{ "idTokens":[ { "id":"https://self-issued.me", "mapping":{ "firstName":{ "claim":"$.given_name" }, "lastName":{ "claim":"$.family_name" } }, "configuration":"https://self-issued.me", "client_id":"", "redirect_uri":"" } ] }, "validityInterval":2592001, "vc":{ "type":[ "VerifiedCredentialExpert" ] } } ``` **COVID-19 Vaccination Credential Sample** ```json { "@context":[ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/vaccination/v1" ], "type":[ "VerifiableCredential", "VaccinationCertificate" ], "id":"urn:uvci:af5vshde843jf831j128fj", "name":"COVID-19 Vaccination Certificate", "description":"COVID-19 Vaccination Certificate", "issuanceDate":"2019-12-03T12:19:52Z", "expirationDate":"2029-12-03T12:19:52Z", "issuer":"did:key:z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3", "credentialSubject":{ "type":"VaccinationEvent", "batchNumber":"1183738569", "administeringCentre":"MoH", "healthProfessional":"MoH", "countryOfVaccination":"US", "vaccine":{ "type":"Vaccine", "disease":"COVID-19", "atcCode":"J07BX03", "medicinalProductName":"COVID-19 Vaccine Moderna", "marketingAuthorizationHolder":"Moderna Biotech" } }, "proof":{ "type":"Ed25519Signature2018", "created":"2021-02-18T23:00:15Z", "jws":"eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..vD_vXJCWdeGpN-qKHDIlzgGC0auRPcwp3O1sOI-gN8z3UD4pI0HO_77ob5KHhhU1ugLrrwrMsKv71mqHBn-dBg", "proofPurpose":"assertionMethod", "verificationMethod":"did:key:z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3#z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3" } } ``` **University Certificate Credential Sample** ```json { "@context":[ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/vaccination/v1" ], "type":[ "VerifiableCredential", "UniversityCredential" ], "id":"urn:uvci:af5vshde843jf831j128fj", "name":"University X Credential", "description":"University X Credential", "issuanceDate":"2019-12-03T12:19:52Z", "expirationDate":"2029-12-03T12:19:52Z", "issuer":"did:key:z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3", "credentialSubject":{ "type":"GraduationEvent", "batchNumber":"1183738569", "administeringCentre":"MoH", "Dean":"Rohan", "Country":"CA", "degree":{ "type":"Graduation", "subject":"Computer Sciences", "subCode":"A90210B" } }, "proof":{ "type":"Ed25519Signature2018", "created":"2021-02-18T23:00:15Z", "jws":"eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..vD_vXJCWdeGpN-qKHDIlzgGC0auRPcwp3O1sOI-gN8z3UD4pI0HO_77ob5KHhhU1ugLrrwrMsKv71mqHBn-dBg", "proofPurpose":"assertionMethod", "verificationMethod":"did:key:z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3#z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3" } } ``` # FAQs
How do we handle Aadhaar verification failures? The workflow fails due to a Know Your Customer (KYC) failure. You can see the reason in the node's Instance results and in the Sessions dashboard in AdminX, along with the individual match indicators (name, date of birth, PIN code, face) that show which check didn't match.
What is the face-match threshold, and is it configurable? The face match threshold is 0.7. A `face_match_confidence` score above 0.7 is accepted. Users and admins can't configure this threshold today because it is part of the workflow that runs on the root tenant.
Where does the liveness check get configured? Liveness for the selfie capture step is configured at the root tenant level, not per workflow or per admin.
What happens if a user doesn't have a DigiLocker account? The user can create one during the redirect. On the DigiLocker screen, they select **Try another way**, which takes them to DigiLocker's account-creation flow.
What happens if a user presents someone else's face during the selfie step? The node still completes because it matches the name, date of birth, and PIN code independently of the face. Only the face match fails: `face_match_result` returns `false` with a `face_match_confidence` below the 0.7 threshold; the other match indicators (name, date of birth, address/PIN) can still return `true` and the overall outcome is **Verification Failed**.
# Release Notes *** ### 2.1.8-r.1 — October 10, 2026 #### What's New **Introducing Verification Analytics: from a pass or fail count to real insights** This release introduces a powerful new capability: **Verification Analytics**, a completely reimagined Analytics experience that gives community administrators a single-page report of verification health. Success rate, first-attempt success, retry rate, time to finish, the top 10 failure reasons, and risk signals are all in one view, calculated only on completed sessions, so abandoned attempts never distort the picture. For the first time, administrators can * Audit verification performance across journeys without pulling data from multiple places * Spot the specific check driving failures * Track whether a fix worked against the prior period, and act on a named cause instead of a generic message For more information, see [Verification Analytics](/identity-verification/monitoring-and-analytics/verification-analytics). **Audit verification activity with the new Sessions (BETA) page** Previously, reviewing identity verification activity meant working with a fixed set of columns and session-level results only, with no way to filter by risk-oriented criteria or see a single person's history across multiple attempts. A new **Sessions** (BETA) page has been added under **Verification** in the AdminX interface, with a customizable table, richer filtering and search, and a new way to view activity grouped by user rather than by individual session. This page is searchable and displays a sessions results table that can be grouped by sessions or grouped by users. It includes nine optional filters and 14 customizable columns to display in the results table. For more information, see [Verification Sessions](/identity-verification/monitoring-and-analytics/verification-sessions). **Detect potential fraud through Risk Signals \[Beta]** This release adds a new layer of fraud visibility: **Risk Signals**, a tab under **Verification** that shows community administrators not just whether a verification passed or failed, but the risky attributes around it. A session can now surface a virtual camera, a document whose country does not match the user's location, or the same face under different identities. Each session carries a risk level and a count of detected signals, so reviewers can see exactly why it looks suspicious. For the first time, fraud patterns that a binary pass/fail hides become visible and auditable. Administrators can disable signals or lower each signal's severity from the default of High, so the page reflects the risks their organization actually cares about. In this phase, signals are report-only and do not change or block the verification outcome. For more information, see [Risk Signals](/identity-verification/monitoring-and-analytics/risk-signals). **Verify user identity through Aadhaar Verification (DigiLocker)** A new Aadhaar Verification (DigiLocker) node is now available in the workflow builder, letting organizations verify a user's identity against their government-issued Aadhaar record. The user enters their details, captures a selfie, and completes verification on the DigiLocker portal; the node then returns the match result. Only the match result is returned — no personal data — so it can be used for users anywhere. This lets organizations add trusted, government-backed identity verification for Indian users with a simple drag-and-drop node and no handling of sensitive Aadhaar data. For more information, see [Aadhaar Verification via DigiLocker](/identity-verification/database-validation/aadhaar-verification-via-digilocker) **Stronger document liveness detection with IDLive Doc** This release adds an additional document liveness check performed through IDLive Doc to improve detection of fraudulent submissions such as photocopies, printouts, and screen captures. When enabled, document scans are additionally evaluated for screen replay, printed copy, portrait substitution, and digital manipulation, with the results shown on the Verification Details page. In this release, these results are for reporting only and do not change or delay the verification outcome. This strengthens fraud detection for physical ID submissions by giving reviewers an extra signal to catch forged or tampered documents. **Detect virtual cameras during selfie capture** Identity proofing now checks whether the selfie camera source looks like a virtual camera — such as OBS Virtual Camera, ManyCam, or CamTwist — and records the finding on the verification session for security review. This detection is informational only; it does not block the user or change the verification outcome, which liveness verification still determines. This helps teams catch attempts to feed a synthetic or replayed image into the selfie step, improving confidence that a real person completed the verification. #### Enhancements * The **Session Details** section in the Verification session UI now displays the actual device model from the session's device signals, falling back to the browser user-agent when a device model is not available. * Verification sessions now preserve the images from every retry attempt instead of keeping only the latest, so all attempts in a session are available for audit and review. #### Bug Fixes * Fixed an issue where starting a new verification session on the same device shortly after a previous session completed or was abandoned could fail with a "Verifier is not found" error, preventing the new session from loading for several minutes. * Fixed an issue where US Uniformed Services IDs could fail verification and show an incorrect date of birth when the document scan did not return one. *** ### 2.1.7-r.2 - September 22, 2026 #### What's New **Improved accessibility and navigation across AdminX** This release adds another round of WCAG improvements across AdminX, Verification, and Workflow, including a new global command palette. **What's new** * **Global command palette** — A new Search control in the AdminX header lets you find and jump to any top-level page. * **Copy to clipboard** on the Session Details page, with keyboard shortcut support. * **New default ID proofing templates**, applied to all tenants automatically; new **Edit template** option on the Verification Flows page. * **Country Code** label added to the Share via text screen. * Sidebar tooltips now stay visible on hover and can be dismissed. * Keyboard focus fixed for the sidebar expand control and session events. * Labeled form fields, keyboard-accessible charts, and contrast-compliant selected states across forms, analytics, calendar, and pagination. * Updated selfie and ID capture screens to a clean white background (visual only). * Removed the multilingual dropdown from the default template; improved the responsive layout across the UI.\ For more information, see [Accessibility](/identity-verification/ux-and-design/accessibility) **Improved image quality for identity verification** High-resolution image capture is now the default for all identity verification journeys. Previously, high-resolution capture was an opt-in setting rarely used, so most journeys processed lower-quality, compressed images. * New and edited journeys capture high-resolution images by default, with no configuration needed. * Customers with bandwidth or storage constraints can opt a journey into low-resolution capture via a backend API setting (off by default; not exposed in the UI). * The previous "use high-resolution images" setting is deprecated but still accepted for backward compatibility. * Existing journeys are unaffected until explicitly changed. * No change to the end-user capture experience or the unsupported document flow. **Remediate known false rejections intelligently** Identity verification now supports a platform-wide bypass for known false-rejection patterns, such as a document template the scanner hasn't caught up to yet or a provider-side barcode issue affecting a whole document type. Previously, each case had to be fixed separately per tenant; now a fix applies everywhere the same issue occurs. * A single, universal rule set is applied to all tenants by default, with no per-tenant setup required. * Applied automatically during tenant bootstrap. * If the bypass service is unreachable, verification fails closed and proceeds through normal checks with no bypass applied. #### Enhancements Verification sessions now retain images from every retry attempt, supporting complete audit and review history. #### Bug Fixes Fixed an issue where document scanning showed a black camera preview on updated iOS devices, blocking verification across Safari, Chrome, and Edge. The camera preview now displays correctly on all iOS browsers. *** ### 2.1.5-r.1 - September 12, 2026 #### What's New **Reduced False Rejections for OCR Spacing During ID Proofing**\ \ Legitimate users were being rejected during identity verification when the document OCR split or spaced a surname differently than how it was enrolled, even though the name was identical. For example, `McMahan` extracted as `MC MAHAN`, or `O'Brien` extracted as `O.BRIEN`, previously failed the last-name check outright because the comparator ran on raw, un-normalized strings at a 100% match threshold.\ This release adds string normalization before the fuzzy match comparison runs, closing this failure class without loosening the threshold or weakening protection against genuinely different names.\ \ **What changed** Before comparing surnames from the authoritative source and extracted surnames, both strings are now normalized: * Internal whitespace is collapsed (`MC MAHAN` → `MCMAHAN`) * Apostrophes and periods are stripped (`O'BRIEN`, `O.BRIEN`, `O BRIEN` → `OBRIEN`) * Hyphenated and unhyphenated variants are treated as equivalent (`SMITH-JONES` = `SMITH JONES` = `SMITHJONES`) * Both sides are uppercased When the last-name fuzzy match threshold is set by the administrator at 100%, normalization will result in `MC MAHAN` → `MCMAHAN` returning a score of 100%. ### 2.1.4-r.1 - August 8, 2026 #### What's New **Improved Retention for Identity Proofing Records and Face Match Accuracy** Identity proofing records — both identity verification results and individual face verification attempts — are now retained for 7 days, giving teams a consistent window for troubleshooting, audit, and downstream retrieval. Previously, these records expired too quickly to retrieve or investigate results in time. Face matching has also been tightened to reduce false positives, lowering the chance that a similar but different face is incorrectly accepted. #### Bug Fixes Fixed an issue where Puerto Rico Driver's License and State ID documents could return incorrect dates during identity verification, which could cause verification to fail. These documents now return the correct date of birth, expiry, and issue dates. *** ### 2.1.3-r.1 - July 11, 2026 #### What's New **Enhanced Device Context Visibility for Identity Verification Sessions** To improve troubleshooting and root-cause analysis of document verification failures, 1Kosmos now captures and displays additional device signals, including Device model information, Image capture resolution, and additional device and browser context used during document capture, within the **Verification Session Details** section of the **View Results** page. **Enhanced Selfie Liveness Retry Configuration** The selfie liveness retry experience for Identity Verification (IDV) has been enhanced with a configurable Max Retry Count (liveness.max\_retry\_count) setting. By default, users are now allowed up to three selfie retry attempts before the verification follows the configured fallback path. Administrators can configure the maximum retry count from 1–10. {% hint style="info" %} **Note**: * The **E\_IDV\_SELFIECAPTURE** event now includes the following fields: * attempt\_number * max\_retry\_count * retries\_remaining * result (retry, success, or fail) * reason (quality or confidence, for retry events) {% endhint %} **API Enhancements** * Added a new ID Proofing endpoint, **POST /proofingsession/{id}/fetch/details**, that returns a proofing session and its session results in a single request, with optional filtering by certificate type. * The DVCID create and update APIs now accept additional properties within the `bypassConfig` object, beyond the standard `enabled` and `criteria` fields. *** ### 2.1.0-r.3 — June 13, 2026 #### What's New **Identify US Real ID Compliance During Document Scanning** The Session Details summary now includes a realIDDetectionStatus parameter indicating whether a scanned document contains the US Real ID star marking. This provides additional transparency during identity verification and helps determine whether a document meets the US Real ID standard. **Retry Document Scanning Without Camera Orientation Issues** Users can now retry document scanning without encountering camera orientation errors, ensuring a consistent and accurate capture experience across retries. **Analyze IDV Sessions Faster with AI-Generated Summaries** 1Kosmos now provides AI-generated summaries for Identity Verification sessions, helping administrators quickly understand verification outcomes without reviewing detailed session data. Each summary is organized into three sections, Session Overview, Failure Reasons, and Key Findings and Recommendations, providing clear, actionable insight into verification results. #### API Enhancements **Perform Selfie-Based Identity Identification via API** A new POST /v1/identify\_selfie endpoint has been added to the 1K Wallet API, enabling applications to perform selfie-based identity identification and retrieve a unique face identifier for biometric verification workflows. #### Bugs Fixed * Fixed an issue where the document scanning camera preview appeared mirrored after an unsupported document was detected during verification. *** ### 1.13.00 — May 15, 2026 #### What's New **Session Summary UI Enhancement for Missing Name Field** The Session Summary has been updated to handle cases where the Name field is unavailable. The field now displays -- instead of appearing blank, ensuring a consistent and clear user interface representation. **Faster LiveID Selfie Startup** LiveID selfie now starts instantly when users open the selfie screen, eliminating the initial loading delay previously experienced. The following performance improvements have been made: Performance improvements apply on first-time access. There is no impact when LiveID selfie is disabled. **Improved User Experience for Front-Only Documents** Documents that only require front-side scanning — including Health Insurance Cards, Metis Cards, PAN Cards, and certain Driver's Licenses in India — no longer prompt users for back-side scanning. This prevents "document not supported" errors and streamlines the capture experience. Additionally, the Data Extracted section on the session UI no longer displays system-derived Date of Issue and Date of Expiry values for PAN cards. Since PAN cards do not contain these fields, they are now correctly shown as N/A. This change applies to all customers. **Fraud Detection UI — Enhanced Checks Breakdown** The Fraud Detection section in the verification results UI has been enhanced to display a more detailed and structured breakdown of fraud checks. Checks are now organized into five categories: * Extracted Data Check (previously labeled "Data"): Includes match check, logic check, field format check, barcode authenticity, suspicious data check, data integrity check, and MRZ check. * Document Liveness: No changes to this category. * Visual Check (new): Displays visual fraud indicators including photo forgery check, security features, and generative AI detection. * Document Validity: Displays expiry and version validation checks. * Image Quality: Displays image quality evaluation results. This enhancement improves transparency by exposing detailed fraud signals within each category, enabling better analysis and troubleshooting of verification results. **Enhanced Session Status in /result API** The /result API now returns granular session states, differentiating between: * Pending — session has been created but not yet started by the user. * In Progress — the user has actively begun the verification process. This aligns the API response with the AdminX interface, ensuring consistent and accurate session tracking for integrations. **Improved Middle Name Matching During Verification Sessions** Name matching when Ignore Middle Name is enabled has been improved for greater accuracy. The system now validates matches based on the presence of all entered name parts, without reducing the match score due to additional names in the document result. Matching is order-independent and requires all entered name parts to be present. Examples: * "Jean Chavez" matches "Jean Carlos Chavez Reyes" ✓ * "Jean C. Chavez" matches "Jean Carlos Chavez Reyes" ✓ * "Chavez Jean" matches "Jean Carlos Chavez Reyes" ✓ * "Jean Chavez Lopez" does not match "Jean Carlos Chavez Reyes" ✗ (name not found) **Selfie Liveness Retry Enhancement** The selfie liveness verification experience has been enhanced with a new retry screen to improve user guidance and reduce failures caused by image quality issues. Previously, selfie liveness verification required both a confidence score and an image quality score to meet the configured threshold for a successful result. With this update, image quality no longer directly causes a liveness failure. Instead, users are guided to retry selfie capture when image quality conditions are not optimal, helping improve completion rates and overall user experience. The retry flow continues until selfie verification succeeds or the configured retry count is exhausted. **Gender Display on Extracted Documents** The Data Extracted section on the session UI now displays gender as M (Male) or F (Female) for passport and driver's license documents, aligning with the official document format. Previously, gender was displayed as numeric values 1 and 2. **Flexible Search for "Completed By" Filter** The Completed By filter in session search now supports flexible search using partial names, full names, first name, or last name, returning matching sessions across all statuses. If no date range is specified, the search defaults to the last 30 days. > Note: Since this feature performs partial matching across non-indexed fields, higher response latency may be observed and is expected behavior. **Accessibility Support for Verification Pages** Accessibility support has been introduced across Verification pages, improving screen reader compatibility, keyboard navigation, and overall user experience. **Improved Handling for Under-21 Document Verification** A bypass configuration has been introduced to support verification of users under 21 years of age using US-issued IDs and Driver's Licenses. #### API Enhancements **Enhanced LiveID Authentication Endpoints** A new optional boolean parameter skip\_liveid has been introduced to the LiveID authentication endpoints. When set to true, liveness detection and face comparison checks are bypassed, while face search/recognition and the standard wallet lookup flow continue as normal. This parameter defaults to false. Affected endpoints: * POST /v1/:tenantId/community/:communityId/authenticate\_with\_liveid * POST /v2/authenticate\_with\_liveid {% hint style="info" %} **Note:** These are LiveID authentication endpoints. When `skip_liveid` is set to `true`, liveness detection and face comparison are bypassed, while face search/recognition and the standard wallet lookup continue as normal. The parameter defaults to `false`. {% endhint %} **New POST /identify\_selfie Endpoint** A new POST /identify\_selfie endpoint has been added to the Wallet API. This endpoint performs face identification and returns a face key, enabling face identification without requiring a full authentication flow. *** ### 1.12.08.03 — April 11, 2026 #### What's New **IAL2 Verification Support for Global Entry and Green Card** Web Identity Wallet now supports Green Card (May 2010 or later) and Global Entry Card for IAL2 requirements. SSN enrollment is enabled once a qualifying document is present. **Improved Verification Success Rate — Extended Name Matching to Last Names** The Ignore middle names capability now supports last name matching in addition to first name comparison. When enabled, the system compares the first word of the first name and the last word of the last name. This setting is now available as a global configuration under the Data Comparison section in AdminX. **Enhanced ID Verification Reports** Reports now include Region, Country, Document Types, and Completed By fields. The "Name" column has been renamed to "Created For". #### API Enhancements * New API added to update proofing templates using verification flows. #### Bug Fixes * Fixed an issue where the "Overall Recommendation" (IDV status) was not displayed to Helpdesk Admin users * Fixed pagination issue where deleting the last record did not navigate to the previous page in Verification Flows * Fixed an issue where scanned document images and selfies failed to render in Microsoft Edge on the Session Details page *** ### 1.12.04.01 — March 14, 2026 #### What's New **Okta BYO IDV Integration** Organizations can now integrate Okta BYO IDV with 1Kosmos to verify identities during onboarding and Self-Service Password Reset (SSPR). See Okta 1Kosmos Identity Verification Integration. **High-Resolution Image Support for Verification** Document capture and image processing now support high-resolution images, improving verification success rates and reducing upload failures. Users see a progress indicator during upload. See Using High-Resolution Images to Improve Verification Success. **AI-Powered ID Proofing Insights \[Beta]** Community administrators or users with the ai.chat\_bot.access permission can now access AI-driven ID Proofing insights via the AdminX chatbot using natural language queries. Capabilities include: session summaries, failure rates, document metrics, regional trends, and tenant-specific insights. See AI-Driven ID Proofing Metrics and Insights. **Verification Filters UI Enhancements** * The None value in the Capture Type field on Session Details is deprecated and removed — now shows only "Auto" and "Manual" * The Review Result and Capture Type filters on the verification list page have been deprecated and removed #### Bug Fixes * Fixed an issue where renewing an expired Affidavit did not restore the user's IAL level from IAL1 back to IAL2 * Fixed an issue where failure reasons were not displayed in the exported IDV report * Fixed an issue in ID Proofing selfie liveness capture where liveness verification consistently failed when the user was positioned at the farthest point * Fixed session status displaying inconsistently across the Verifications list page, Session Details, and downloaded reports * Fixed an issue where Identity Verification reports could not be downloaded for specific journeys * Fixed an issue in IDVerification Analytics where chart data was displayed incorrectly in the 7-day view due to time zone difference *** ### 1.12.01.01 — February 14, 2026 #### What's New **Expiry Status Indicators for Enrolled Documents** The AdminX interface now displays expiry status for previously enrolled documents and affidavits in the Identity Wallet tab under My Profile. Two indicators are displayed: * Expiring Soon — for documents expiring within 30 days * Expired — for documents that have already expired, prompting re-enrollment **Manual Document Capture When Auto Capture Fails** Community administrators or users with permission to configure DVCIDs can now manually capture an identity document if automatic capture fails after a timeout. Depending on backend configuration, users will see a Manual Capture button or a countdown-based capture. Supported in both v1 and v2 verification flows. See Verification Journey. **Manual Review of Verification Sessions** Community administrators or users with the idproofing.manual-review permission can now review certain ID verification sessions later or offline. When used, the session moves into a Review state. Users can filter sessions by: status, overall recommendation (including 'review'), review result (approved/rejected/review pending), and fallback capture mode. An E\_IDV\_MANUAL\_REVIEW\_DECISION event is triggered after the user approves or rejects the ID proofing session. **Review Status in Usage Analytics** The Usage Analytics page under Verification > Analytics now displays the Review status in the Verifications Breakdown tile. **Enhanced Name Matching for Identity Verification** A new Ignore Middle Names option is now available in the AdminX verification flow configuration. When enabled, middle names are excluded from name comparison during ID proofing, reducing false failures caused by middle name mismatches between directory data and identity documents. See Configuring Verification Flows. **Configuring Data Retention Based on Session Outcome** Administrators can now configure data retention policies based on ID verification session outcomes for each outcome type: Success, Failed, Not Performed, Review, and Abandoned. Available when creating a verification flow using the KYC with Face Comparison journey. See Configuring Verification Flows. **New Permission — idproofing.manual-review** Added to control access to the manual review functionality. #### Bug Fixes * Fixed an issue where the selfie\_liveness "skip": true setting in the DVCID face\_liveness configuration was overridden if a user opened and saved the V2 DVCID settings in the UI, even without making any changes. *** ### 1.12.00.01 — January 10, 2026 #### Miscellaneous * Updated site description for ID proofing session URLs to: "Secure link to complete identity verification" * Added warning message "Provide another tag, this tag already exists" to the Unique Tag field in Create Verification Flow #### Bug Fixes * Fixed an issue where ID proofing sessions failed with an unsupported document error when the template did not include a consent or Start Now screen *** ### 1.11.09.01 — December 13, 2025 #### What's New **Automatic Camera Selection During Document Scan** Administrators can now use the new camera\_enforcement property in the ID proofing template to specify whether the front or back camera should be used during document scanning. Values: front, back, or default. > Note: This is part of the V2 DVCID config. **LiveID Capture Enhancements** * Removed repeated "keep your eyes open" prompts under low-light conditions or when wearing glasses * LiveID capture time reduced to 600 milliseconds * The capture circle now turns red when no face is detected and light green when a face is recognized; a darker green animated ring shows capture progress * New UI guidance messages: "Center your face in the circle", "Move closer", "Move back a little", "Keep your head level", "Face the camera directly" {% hint style="info" %} **Note:** * These are LiveID authentication endpoints. Setting `skip_liveid` to `true` bypasses liveness detection and face comparison, while face search/recognition and the standard wallet lookup continue as normal. * These enhancements apply to the LiveID selfie-capture experience and are used across both identity verification and LiveID login flows. {% endhint %} **Optimized Camera Permissions Overlay During Document Scan** Fixed an issue where granting camera permissions after a 40-second idle caused a "No camera detected" error. Once permission is granted, the camera now opens correctly. #### Bug Fixes * Resolved an issue where v2 DVCIDs configured with only SSN, Face Compare, or AAMVA checks would trigger errors in the Verify API after migration from v1 * Resolved intermittent failures when downloading ID Proofing reports *** ### 1.11.08 — November 15, 2025 #### What's New **Improved SSN Verification Success Rate** Name matching requirements for SSN document checks have been relaxed — verification will no longer fail due to minor name differences between SSN data and the ID document. #### API Enhancements * The {{tenantDNS}}/api/r1/community/{{community\_name}}/userid/johndoe/ial API now includes the expiry date (YYYYMMDD format) for all documents enrolled in the wallet #### Bug Fixes * Fixed LiveID capture failing during identity verification on Android and iOS with "Face not found" error *** ### 1.11.06.01 — October 10, 2025 #### What's New **Configure Identity Verification Flow Through UI** Community administrators with the idproofing.add-journey permission can now configure and manage custom ID verification journeys in AdminX under Verification > Verification Flows. Key capabilities: creating and managing journeys, generating and sharing session links, editing or deleting journeys, and defining accepted ID documents by country and region. See Configuring Verification Flows. **Granular Document Controls for ID Verification** Administrators can now define which identity documents are allowed or blocked during the ID Verification journey — by country, region, and document type. A new event E\_IDV\_DOCUMENT\_NOT\_ALLOWED is triggered with full metadata when a user scans a blocked document. **Enhanced IAL2 Identity Verification Flow** Users can now enroll their LiveID to a wallet, enabling future comparisons against identity documents stored in the wallet. Administrators can configure whether LiveID capture appears within the verification flow or in a separate tab. If the initial selfie session does not start within 2 seconds, a new session is automatically created. **New Form Input Controls** A new form step has been introduced in the verification flow, allowing users to enter information through various input types: text, number, password, email, date, and checkbox fields. *** ### 1.11.04 — September 5, 2025 #### What's New **One-Time IAL2 Identity Verification** Community administrators can now create and manage a one-time Identity Assurance Level 2 (IAL2) verification flow requiring two identity documents, biometric data, and an SSN. User identity data is not stored after verification. See Kantara Certified IAL2 Verification. #### API Enhancements * Session poll API enhanced with a new responseStatus parameter {% hint style="info" %} **Note:** The Session poll API returns the verification session status through the new `responseStatus` parameter, consistent with the V3 Poll API. {% endhint %} #### Deprecated * The expiry timestamp (expiryTs) has been removed from IDProofing event data. Data retention is now handled through dedicated database archiving processes. *** ### 1.11.02 — August 9, 2025 #### What's New **Manual Document Capture Support** The verification UI now supports manual document capture when auto-capture fails. Fallback options include Manual Capture and Retry Auto buttons appearing after a timeout. > Note: Controlled via a configuration flag; may not be available in all environments. **Enhanced V3 Poll API** * Added liveid\_object key containing selfie details * Included rawData for session-level raw information * Added token, reason, reasonCode, and fuzzyMatchScore * Updated resultStatus for sessions where verification was not performed to return NOT\_PERFORMED instead of FAILED #### Bug Fixes * Fixed Take Selfie button remaining disabled even when face is correctly positioned * Fixed "No camera detected" error after a previous document capture attempt failed * Fixed incorrect error codes when scanning expired or photographed documents *** ### 1.11.00 — July 12, 2025 #### What's New **Two New Languages in ID Proofing Templates** Simplified Chinese and Spanish have been added, expanding support to four languages: English, French, Simplified Chinese, and Spanish. **Retry Mechanism for Unsupported Documents** A retry mechanism has been implemented with configurable attempt limits. An E\_IDV\_SESSION\_RETRY event is displayed when a retry attempt is made. **Passport Instructional Text in Vertical Mode** Instructional text during passport scanning is now properly aligned and readable in both vertical and horizontal orientations. **Enhanced SSN Behavior During Verification** When multiple records are returned for the same user, the system now selects the record(s) with the highest idVerificationScore. If a unique match is found, verification proceeds; otherwise it fails gracefully. *** ### 1.10.19 — June 14, 2025 #### What's New **WCAG Compliance for ID Proofing Templates** 1Kosmos has implemented Web Content Accessibility Guidelines (WCAG) compliance for ID Proofing Templates. Voiceover support has been introduced across all screens for visually impaired users. Key elements and instructions are now fully navigable and readable using the keyboard. **reCAPTCHA on Verification Journeys** reCAPTCHA verification has been added to the Verification > Journeys page when an administrator sends a session link via SMS. If reCAPTCHA config is missing, the admin will see: "Recaptcha configuration is missing, please contact your administrator." #### Miscellaneous * New /proofingsession/recaptcha\_config/fetch API added *** ### 1.10.18.01 — May 12, 2025 #### What's New **Retry Mechanism for ID Proofing Sessions** Community administrators can configure the number of retry attempts (default: 2, max: 5) when users fail verification. If the retry count is set above 4, the UI prompts the administrator to correct the configuration. See Verification Journey. #### Bug Fixes * Fixed document enrollment error for IAL2 in SAML/OIDC authentication flow *** ### 1.10.17 — April 12, 2025 #### What's New **Expired and Abandoned Statuses in ID Proofing** Two new statuses added: Expired and Abandoned. * Default expireSessionInMin: 7 days * Default abandonSessionInMin: 1 hour * New events: E\_IDV\_SESSION\_EXPIRED and E\_IDV\_SESSION\_ABANDONED See ID Verification Events. *** ### 1.10.16.01 — March 15, 2025 #### What's New **Adding Affidavit on Behalf of a User** Community/Helpdesk administrators can now add an affidavit to a user's web wallet allowing them to become IAL2 certified without physically scanning documents. Required permissions: user.affidavit.add, users.view-user, users.edit, users.all-users. See Bypassing Verification Using Notarized Documents. > Note: New users will no longer be required to enter a PIN. **Filter Verification Results by Journey Name and UID** Two new filters — Journey Name (DVCID) and UID — have been added to the Verification > Verification page. See Verification Journey. *** ### 1.10.15 — February 21, 2025 #### What's New **Download Verification Results** Community administrators or users with idproofing.reports.verification-sessions-download or idproofing.session-management permissions can now download verification reports from AdminX under Verification > Verification. Reports can be filtered by document type, verification status, and completed by. If the report exceeds 2 million records, users will be prompted to refine their search. See Downloading Verification Reports. *** ### 1.10.14 — January 10, 2025 #### What's New **IAL2 Device Removal Warning** When an end user attempts to remove an IAL2-authenticated device from the Devices tab under My Profile, a warning message now appears alerting them of the impact. *** ### 1.10.13.01 — December 14, 2024 #### What's New **New Verification Status — Verification Not Performed** A new status distinguishes cases where fraud verification could not be completed. Displayed when: * Verification process is partially completed * Front side of document is processed but backside is unclear * Document extraction process fails * Unsupported document is submitted See Verification Journey. *** ### 1.10.12 — November 8, 2024 #### What's New **New Filters for ID Proofing Verification Events** New filter values added: Authenticator ID, Device ID, Mobile Document ID, Mobile Session ID. *** ### 1.10.03 — April 25, 2024 #### What's New **Fraud Detection Panel** Community administrators can now view which specific verification check failed when identity verification is deemed fraudulent. **Confidence Score Retention While Discarding PII** Administrators can selectively discard PII while retaining confidence scores for the verification journey. A new summary object within the session result stores confidence scores for all verification checks. **ID Verification Session Metrics** A new analytics page displays the count of verification sessions completed, passed, and total sessions generated, with a 90-day time-series graph. **Reduced Verification Time** Significant performance optimizations reduce the overall time required to submit images and receive a verification result. *** ### 1.10.00 — February 10, 2024 #### What's New **Web Identity Wallet — ID Cards from Any Country** For tenants subscribing to the web Identity Wallet, 1Kosmos now supports enrollment of ID cards from any country and document. Expired ID cards cannot be enrolled. When enrolled, users can view document details. *** ### 1.09.04 — May 18, 2023 #### What's New **Unenroll Documents from Identity Wallet** Users can now remove identity documents (driver's license, passport, and SSN) from their identity wallet. Once removed, data from the document is no longer available. The user's IAL is recalculated when a document is removed. *** ### 1.09.02 — April 13, 2023 #### What's New **Trigger Identity Verification Flow Using OIDC** OIDC clients can trigger an identity verification flow by including the /assurance/ial/2 custom scope. The platform checks if the user is verified to IAL2 and, if not, triggers a verification flow. #### Improvements and Bug Fixes * Improved page load times for identity wallet document uploads *** ### 1.07.06.01 — January 5, 2023 #### What's New **Trigger IAL2 Verification Using OAuth2/OIDC** Passing ial2 as an acr value on an OIDC claim triggers an authentication journey for users to upload and verify identity documents online, resulting in IAL2 verification. *** ### 1.07.03 and v1.07.04 — November 17, 2022 #### Improvements and Bug Fixes * Silently handled AAMVA timeout responses to allow users to proceed * Fixed Driver's License enrollment to the Identity Wallet when AAMVA verification fails *** ### 1.07.02 and v1.07.03.02 — October 20, 2022 #### Early Access **Verify Identity with Passport** The 1Kosmos Identity Wallet now supports enrollment of a US Passport. For IAL2 credentialing, the user must additionally verify their SSN. **Passport Attributes** The 1Kosmos platform allows the CSP to request passport attributes through SAML or OIDC workflows with user consent. *** ### 1.07.01 and v1.07.00 — September 12, 2022 #### Deprecated * Enrollment of GovID documents by attributes request. Enrollment is now supported based on Authn Context of the incoming request. *** ### 1.06.04 — May 26, 2022 #### What's New **Web-Based Identity Proofing Journey** Introduced a new web-based identity proofing journey with capabilities to: * Allow users to self-enroll and create an account * Create a new identity wallet after registration * View identity documents connected to the user profile * Trigger text messages to scan a GovID * Enroll a driver's license as an identity document * Validate driver's license against AAMVA * Enroll and validate SSN * Triangulation logic to verify Driver's License and SSN belong to the same user * Present data sharing and consent screens * Trigger proofing journeys based on incoming requests from a relying party * New SAML attribute set for sharing identity document data # Getting started with passwordless authentication This guide introduces passwordless authentication. You'll understand how authentication works, what you can protect with it, and the steps to go from a new tenant to a working passwordless login. *** ### What it is 1Kosmos replaces passwords with phishing-resistant, biometric authentication. Instead of a shared secret that can be stolen, reset, or phished, each sign-in is tied to a verified identity and backed by FIDO2 cryptographic keys. Users enroll their identity once and can then authenticate across systems, online or offline, without carrying a password or a separate hardware token for every app. Because credentials are never stored or transmitted in a way an attacker can reuse, common attacks like phishing and credential stuffing are designed out rather than defended against. Teams typically also see fewer password-reset tickets, since recovery is handled through self-service biometric verification. ### How authentication works Authentication happens in three stages: 1. **Verify identity with biometrics.** The user proves who they are with a biometric check that meets NIST IAL2/AAL2 assurance levels. Because the verified identity is stored in the cloud rather than bound to a single device, users can enroll once and authenticate from anywhere. 2. **Unlock cryptographic keys.** A successful biometric check unlocks the user's FIDO2 private key locally. No password or reusable credential is sent over the network, which is what makes the flow resistant to phishing. 3. **Authenticate across systems.** The same verified identity works across desktops, servers, web apps, SSO platforms, VPNs, and privileged systems, whether the device is online or offline. ### What you can secure | Scenario | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SSO & applications | Authenticate once with biometrics and reach connected apps. Integrates with Microsoft, Okta, Ping, Saleforce, G-Suite, Entra EAM or Adaptive MFA can raise or lower friction based on risk. | | Workstations | Sign in to Windows, macOS, and Linux desktops, servers, and VDI with face or fingerprint, governed by centralized policy. | | Network & legacy systems | Extend passwordless to VPNs, network devices, and older applications over standard protocols, without rewriting them. | | Shared devices | Workers authenticate at any shared terminal with a fingerprint after a one-time enrollment. | | Shared accounts | Behavioral verification ties each action on a shared account back to an individual, producing a full audit trail. | # Overview The Windows Workstation MFA Agent adds multi-factor and passwordless authentication to the Windows login experience, controlled centrally from AdminX Portal.
Windows Workstation Login Screen
### What is Windows Workstation MFA Agent? The 1Kosmos Windows Workstation MFA Agent is a Windows Credential Provider that adds multi-factor and passwordless authentication to the Windows login experience. Once installed on a workstation or server, it intercepts the standard Windows sign-in flow and requires users to verify their identity through a second, or sole, authentication factor before access is granted. The agent integrates with your organisation's Active Directory through the 1Kosmos platform and is managed centrally from the AdminX administration portal. Authentication policies can be scoped to specific users, AD groups, or individual machines, giving administrators precise control over who authenticates how and where. The agent supports both **MFA** (password plus an additional factor) and **passwordless** (no password required) authentication modes, depending on the journey configured in AdminX. ### How it Works The agent operates as a custom Windows Credential Provider. When a user signs in, at the physical console, over Remote Desktop (RDP), or via a Run As / CredUI prompt, the agent presents the 1Kosmos authentication interface alongside or in place of the standard Windows password prompt. Authentication can be initiated from two entry points on the Windows login screen: * **User tile** the agent presents the configured authentication factors directly, without requiring the user to type their username first. * **Other User tile** the agent prompts for a username first, then presents the authentication factors. Once the user completes the configured authentication journey, the agent passes the validated credential to Windows and the session begins. *** ### Supported Login Scenarios The table below covers every login scenario the agent supports and the authentication modes available for each. | Scenario | MFA with Password | Passwordless | | -------------------------------------------------- | :---------------: | :----------: | | Workstation login | ✅ | ✅ | | Workstation unlock (after screen lock) | ✅ | ✅ | | Remote Desktop (RDP) — incoming | ✅ | ✅ | | Remote Desktop (RDP) — outgoing via host machine | ✅ | ✅ | | Run As / CredUI (UAC elevation) | ✅ | ✅ | | Shared account login (via CyberArk PAM) | ✅ | ✅ | | Offline login (no internet / platform unreachable) | ✅ | ✅ | | Local account login (break-glass) | ✅ | ❌ | ### Supported Authentication Methods Which methods appear at login depends on the adaptive authentication journey configured for the user in AdminX. | Method | Requires Mobile App | Works Offline | | ------------------------------------------- | :-----------------: | :------------: | | Password | ❌ | ✅ | | Push Notification | ✅ | ❌ | | TOTP (1Kosmos App) | ✅ | ❌ | | QR Code | ✅ | ❌ | | LiveID | ❌ | ❌ | | FIDO / 1Key (single-user or multi-user key) | ❌ | ❌ | | SMS OTP | ❌ | ❌ | | Email OTP | ❌ | ❌ | | Voice OTP | ❌ | ❌ | | Behavior Auth + PIN | ❌ | ✅ (cached PIN) | | Offline Account OTP | ✅ | ✅ | {% hint style="info" %} **Note:** SMS, Email, and Voice OTP require the user's phone number or email address to be present on their Active Directory profile. {% endhint %} *** ### What's Not Covered The Windows Workstation MFA Agent does **not** apply 1Kosmos authentication to the following scenarios. These remain controlled by Windows native authentication only. * **Pre-boot / BitLocker unlock** — The agent operates after BitLocker unlocks the drive. It does not replace or integrate with BitLocker pre-boot authentication. * **Non-interactive logon types** — Log on as a Service, Log on as Batch Job, Scheduled Tasks, and network drive mappings are not intercepted by the agent. * **PowerShell remoting** — `Enter-PSSession` and `Invoke-Command` are not covered. * **RDP Restricted Admin Mode** — The agent does not intercept Restricted Admin Mode RDP sessions. * **Third-party credential providers** — The agent coexists with other credential providers (e.g., Windows Hello, smart card) but does not manage or replace them. Interaction with third-party disk encryption (e.g., Trellix Drive Encryption) may require additional registry configuration, see [FAQs](/authentication/windows-workstation-mfa/faqs). *** ### What's New The table below summarises significant changes across recent releases. For the full version history including bug fixes, see [Release Notes.](/authentication/windows-workstation-mfa/release-notes-for-windows-workstation-mfa)
VersionReleasedKey Changes
2.4.6.0July 2026MFA for local Windows accounts (password + MFA via CaaS); OTP & push rate limiting on Windows CP; offline PIN/OTP fixes and corrected login event reporting
2.4.5.0June 2026Full session lifecycle tracking (offline-queued); forced Behavioral Auth after offline PIN login; offline PIN logins in audit trail; security fixes
2.4.4.0May 2026Behavioral Auth enrollment enforcement (Skip option removed, community-level config); TPM-accelerated smart card login (~20s → 9–11s with auto fallback and cert renewal); multi-language CP UI & Behavioral Auth phrases (Spanish, Portuguese, French, German, OS auto-detect); case-insensitive offline PIN username resolution (incl. "Other User" tile winuserattribute mapping)
2.4.3.0
2.4.2.0Faster LiveID login (upfront camera init, preloaded pipeline, DSHOW fallback); security fixes
2.4.0.0March 20261Kosmos rebranding (BlockID references removed); MSI auto-dependency check; LiveID early camera warm-up for faster biometric login
2.3.0.0March 2026MSI package installation support introduced recommended installer for all new deployments
2.2.0.0March 2026Fallback authentication via helpdesk passcode; offline PIN authentication (no mobile app required)
2.1.5.xNov 2025 – Feb 2026Password-based shared account access; command-line installer parameters; dynamic CP disable via registry; PIN lockout notifications
2.1.4.0Nov 2025FIDO debug logs (1KosmosFIDOLogs.txt); security hardening
2.1.3.0Oct 2025Granular password provider filtering (Login vs. CredUI); last-used provider clearing
2.1.2.0Sep 2025Behavior Auth + PIN (typing biometrics) introduced
# System Requirements This page lists the supported operating systems and minimum hardware specifications for Windows. *** ### Hardware | Component | Minimum Requirement | Notes | | -------------------- | --------------------------------------------------------- | -------------------------------------------------------------- | | RAM | 16 GB | — | | Processor | 4 physical cores, Intel 8th Gen / AMD Ryzen 2000 or newer | Clock speed alone is not a sufficient indicator of performance | | Disk Storage | 256 GB SSD (NVMe preferred; SATA SSD acceptable) | Spinning HDDs are not supported for production deployments | | .NET Framework | 4.7.2 or higher | — | | VC++ Redistributable | 2015–2022 | — | ### Supported Operating Systems | Operating System | Support Status | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Windows 11 | ✅ Fully Supported | | Windows 10 | ⚠️ Currently supported. While no immediate changes are planned, support will be deprecated in a future release as Microsoft no longer provides security updates for this OS (EOL: October 14, 2025). Customers are advised to plan their upgrade path accordingly. | | Windows Server 2022 | ✅ Fully Supported | | Windows Server 2019 | ✅ Fully Supported | | Windows Server 2016 | ⚠️ Currently supported. While no immediate changes are planned, support will be deprecated in a future release as Microsoft mainstream support ended January 2025. Customers are advised to plan their upgrade path accordingly. | ### Runtime Dependencies | CP Version | Installer | .NET Requirement | VC++ Requirement | Auto-Installed | | ---------- | --------- | -------------------- | ---------------------------------------- | ------------------------- | | v2.x | MSI | .NET Framework 4.8.1 | VC++ Redistributable 2015–2022 (v14.42+) | Must be pre-installed | | v2.x | EXE | .NET Framework 4.7.2 | VC++ Redistributable 2015–2022 | Auto-installed (EXE only) | {% hint style="info" %} MSI installer does not auto-install dependencies. Must be pre-installed or included in SCCM/Intune package. {% endhint %} *** ### Network & Connectivity Requirements #### Required Outbound Access | Destination | Port | Protocol | Purpose\*. | | -------------- | ---- | ---------------- | ------------------------------- | | \*.1kosmos.net | 443 | HTTPS / TLS 1.2+ | 1Kosmos platform authentication | {% hint style="info" %} **Note:** Firewall rules based on IP addresses are not recommended, as endpoints may change. Use FQDNs. {% endhint %} #### TLS Requirements The agent requires TLS 1.2 or higher. TLS 1.0 and TLS 1.1 are not supported. #### Proxy Configuration | Proxy Type | Supported | | ----------------------------------------- | --------- | | Unauthenticated proxy | ✅ | | Authenticated proxy (username + password) | ✅ | | PAC file proxy | ✅ | | NTLM proxy | | See Configuration Reference for configuration steps. *** ### 1Kosmos Platform Prerequisites Complete these steps in AdminX **before** deploying the agent. Installing the agent before completing these steps will cause authentication failures. * [ ] **Tenant / Community is set up** — Tenant must be provisioned. Contact your 1Kosmos representative if you haven't done this. * [ ] **Active Directory** — Configured via the AdminX Broker. Users must exist in the directory before they can authenticate. See Authentication Broker. * [ ] **Windows MFA application is configured in AdminX** — Navigate to **Applications > Windows MFA** and confirm the application exists. * [ ] **At least one Adaptive Auth Journey is configured** — Users without a matching journey will see the default authentication options. See AdminX Configuration. * [ ] **Users are enrolled in their authentication method** — the mobile app must be linked for Push / TOTP / QR Code authentication; 1Key must be enrolled for FIDO; Behavior Auth + PIN enrolls at first login. *** ### Installer Selection Guide Two installer formats are available. Choose the appropriate format before you begin; switching formats later requires a full uninstall and reinstall. #### EXE vs MSI | Feature | EXE | MSI | | -------------------------- | -------------------------------------------- | ----------------------------------------- | | Silent install | ✅ (`/SILENT`, `/VERYSILENT`) | ✅ (`/qn`) | | SCCM / Intune / GPO | ⚠️ Possible but more complex | ✅ Native support | | Auto-installs dependencies | ✅ Yes | ❌ Must be pre-installed | | Configuration method | command-line params + `REGCONFIG.ini` (v2.x) | Windows Registry via `registryconfig.ini` | | Supported CP version | v2.x | v2.x only | {% hint style="info" %} **Migrating from v2.1 to v2.2?** See Upgrade & Migration. Note that `config.json` is not used in v2.x MSI installations, all configuration moves to the Windows Registry. {% endhint %} # Installation The Windows Workstation MFA Agent supports two installer formats. Choose the right one for your environment before proceeding, switching formats later requires a full uninstall and reinstall. *** | If you are... | Go to... | | ----------------------------------- | ------------------------------- | | Starting a new deployment | Install using MSI (Recommended) | | Done installing and ready to verify | Post-installation Verification | {% hint style="info" %} **New deployment?** Use the MSI installer. It supports silent installation, SCCM, Intune, and GPO natively and is the recommended method for all new deployments from v2.3.0.0 onwards. {% endhint %} # Install using MSI The MSI installer is the recommended method for all new deployments. It supports silent installation, SCCM, Intune, and GPO deployment natively. *** ### Prerequisites Before running the MSI installer, ensure the following dependencies are installed on the target machine. The MSI installer does NOT install these automatically, unlike the EXE installer. | Dependency | Minimum Version | Download | | ---------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------- | | Microsoft Visual C++ Redistributable 2015–2022 | v14.42 or later | [Download from Microsoft](https://aka.ms/vs/17/release/vc_redist.x64.exe) | | .NET Framework | 4.8.1 or later | [Download from Microsoft](https://dotnet.microsoft.com/en-us/download/dotnet-framework/net481) | {% hint style="info" %} If either dependency is missing, the MSI installation will fail silently. Verify both are installed before proceeding. {% endhint %} ### UI Mode Installation 1. Obtain the installer package from your 1Kosmos representative. The package contains: * `1KosmosCredentialProvider-.msi` * `registryconfig.ini` 2. Right-click `1KosmosCredentialProvider-.msi` and select **Run as administrator**. 3. Follow the on-screen installation wizard. 4. Default installation directory: `C:\Program Files\1Kosmos\1KosmosCredentialProvider` 5. Log files are available at: `C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs` 6. Restart the workstation after installation is complete. {% hint style="info" %} A restart is required for the Credential Provider to appear on the Windows login screen. {% endhint %} ### Silent Installation For deployments where no user interaction is required. To install silently (no UI, no restart): **Install silently with no UI and no restart:** `msiexec /i 1KosmosCredentialProvider-.msi /qn /norestart` **Install silently with registry configuration applied at install time:** `msiexec /i 1KosmosCredentialProvider-.msi /qn REGISTRYCONFIG="C:\temp\registryconfig.ini" /norestart` **Install with wizard visible but no user input required:** `msiexec /i 1KosmosCredentialProvider-.msi /norestart` **Install with wizard visible and registry configuration:** `msiexec /i 1KosmosCredentialProvider-.msi REGISTRYCONFIG="C:\temp\registryconfig.ini" /norestart` {% hint style="info" %} **`/norestart`:** Use when deploying via SCCM or Intune to control the restart separately. Without this flag, the installer restarts the machine immediately after installation. {% endhint %} {% hint style="info" %} **`REGISTRYCONFIG`:** The path must be a full absolute path. Relative paths are not supported. {% endhint %} ### Configuring registryconfig.ini The `registryconfig.ini` file applies tenant connection details and registry settings during installation. It is included in the installer package received from your 1Kosmos representative. | Registry Key | Type | Description | Example Value | | ---------------------- | ---------- | -------------------------------------------------------------------------- | -------------------------------------- | | tenantUrl | REG\_SZ | Tenant URL to connect to the 1Kosmos platform | acme.1kosmos.net | | communityName | REG\_SZ | Name of the 1Kosmos community | default | | proxyUrl | REG\_SZ | URL of the proxy server (optional) | | | proxyUsername | REG\_SZ | Username for authenticated proxy (optional) | username | | proxyPassword | REG\_SZ | Password for authenticated proxy (optional) | \[your proxy password] | | VaultUrl | REG\_SZ | CyberArk vault URL (shared account deployments only) | sampletest.privilegecloud.cyberark.com | | VaultUser | REG\_SZ | CyberArk vault service account username | svc\_account | | VaultUserCredential | REG\_SZ | CyberArk vault service account password | \[your vault password] | | VaultProxyUrl | REG\_SZ | CyberArk proxy URL (optional) | 192.168.0.0 | | VaultProxyApiKey | REG\_SZ | CyberArk proxy API key | d0f100ab-xx76-4xx8-bxc2-7xx175xxx22b | | RdpDisabled | REG\_DWORD | When set to 1, bypasses RDP logins allowing native credential passthrough | 0 | | ClearLastUsedProvider | REG\_DWORD | When set to 1, OS does not remember the last used provider | 0 | | DisablePwdOnLogin | REG\_DWORD | When set to 1, disables the password provider during Login/Unlock | 0 | | DisablePwdOnCredUI | REG\_DWORD | When set to 1, disables the password provider during CredUI (Run As / RDP) | 0 | | Disable1KosmosOnLogin | REG\_DWORD | When set to 1, hides the 1Kosmos Credential Provider during Login/Unlock | 0 | | Disable1KosmosOnCredUI | REG\_DWORD | When set to 1, excludes 1Kosmos from CredUI flows | 0 | {% hint style="warning" %} The `registryconfig.ini` file does not support double quotes in any value. Passwords containing double quotes will cause configuration to fail. {% endhint %} {% hint style="info" %} All configuration is applied to the Windows Registry. The `config.json` file used in EXE v1.x installations is not used by the MSI installer. {% endhint %} *** ### Mass Deployment #### SCCM / Microsoft Endpoint Configuration Manager `msiexec /i 1KosmosCredentialProvider-.msi /qn REGISTRYCONFIG="\\server\share\registryconfig.ini" /norestart` Pre-stage the `registryconfig.ini` file to a network share or include it in the deployment package. Schedule the restart through SCCM separately. #### Microsoft Intune Wrap the MSI using the Microsoft Win32 Content Prep Tool (`IntuneWinAppUtil.exe`) and create a Win32 app in Intune with the following settings: **Install command:** `msiexec /i 1KosmosCredentialProvider-.msi /qn REGISTRYCONFIG="C:\temp\registryconfig.ini" /norestart` **Uninstall command:** `msiexec /x 1KosmosCredentialProvider-.msi /qn /norestart` **Detection rule:** File detection on `C:\Program Files\1Kosmos\BlockIDCredentialProvider\` #### Group Policy (GPO) Add the MSI to a GPO software installation policy targeting the relevant computer OUs. {% hint style="info" %} GPO software installation does not support passing MSI properties such as `REGISTRYCONFIG` directly. Configure registry settings separately using a GPO Registry preference or a startup script that runs the silent install command with the `REGISTRYCONFIG` parameter. {% endhint %} # Install using EXE (Legacy) The EXE installer is supported for existing deployments and manual installations. For all new deployments, use the MSI installer instead. *** {% hint style="warning" %} The EXE installer is maintained for existing deployments and will be deprecated in a future release. If you are starting a new deployment, see **Install using MSI (Recommended)**. {% endhint %} ### Installer Package Contents The EXE installer package received from your 1Kosmos representative contains the following files: | File | Purpose | | ------------------------------ | --------------------------------------- | | 1KosmosCredentialProvider-.exe | Installer executable | | 1KosmosInstaller.bat | Batch script for automated installation | | REGCONFIG.ini | Registry configuration file | {% hint style="info" %} The `config.json` file is no longer included in the installer package from v2.4.0.0 onwards. All configuration is handled via `REGCONFIG.ini` and the Windows Registry. {% endhint %} *** ### Manual Installation 1. Right-click `1KosmosCredentialProvider-.exe` and select **Run as administrator**. 2. Accept the licence agreement and click **Next**. 3. Review the installation location and click **Next**. 4. Click **Install**. 5. When complete, restart the workstation. 6. Click **Finish**. Default installation directory: `C:\Program Files\1Kosmos\BlockIDCredentialProvider` Log files: `C:\Program Files\1Kosmos\BlockIDCredentialProvider\Logs` {% hint style="info" %} A restart is required for the Credential Provider to appear on the Windows login screen. {% endhint %} *** ### Batch Script Installation The `1KosmosInstaller.bat` script automates installation and registry configuration. #### Basic installation `1KosmosInstaller.bat -install 1KosmosCredentialProvider-.exe` #### Installation with registry configuration Open the `REGCONFIG.ini` file and add your values: ``` VaultUrl=sampleurl VaultUser=sampleuser VaultUserCredential=samplecred VaultProxyUrl=sampleurl VaultProxyApiKey=sampleapikey RdpDisabled=0 ClearLastUsedProvider=0 DisablePwdOnLogin=0 DisablePwdOnCredUI=0 CommunitySeed__= ProviderIcon= UILogo= ``` Then apply the configuration: `1KosmosInstaller.bat -configure REGCONFIG.ini` #### Install, configure, and restart in one command `1KosmosInstaller.bat -install 1KosmosCredentialProvider-.exe -configure REGCONFIG.ini -restart` ### Uninstall `1KosmosInstaller.bat -uninstall` {% hint style="warning" %} * Values in the `REGCONFIG.ini` file must not contain double quotes. Passwords containing double quotes will cause the script to fail. * The `-install` and `-uninstall` commands cannot be run simultaneously. * The `REGCONFIG.ini` file is automatically deleted after the `-configure` command completes. * This script can also be used to upgrade an existing installation. {% endhint %} # Post-installation Verification After installing the agent, complete these steps to confirm the Credential Provider is active and authentication is working before rolling out to users. *** #### Step 1 - Verify the Agent Appears on the Login Screen 1. Restart the workstation if you have not already done so. The Credential Provider needs a restart for install completion 2. On the Windows login screen, confirm the **1Kosmos** tile is visible in Sign-In options. 3. The tile displays the 1Kosmos logo. If you have configured a custom logo via the `ProviderIcon` registry key, your organisation's logo will appear instead. If the 1Kosmos tile is not visible after restart: * Confirm the installation completed without errors. Check logs at `C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs`. * Confirm `tenantUrl` and `communityName` are correctly configured in the Windows Registry (MSI) or `REGCONFIG.ini` (EXE) * Confirm all runtime dependencies are installed * See **Troubleshooting** for further guidance *** #### Step 2 - Verify Connectivity to the 1Kosmos Platform Before testing authentication, confirm the workstation can reach the 1Kosmos platform. 1. Open a browser on the workstation and navigate to your tenant URL (e.g., `https://acme.1kosmos.net`). 2. Confirm the page loads without certificate errors or timeouts. 3. If the page does not load, review your Network & Connectivity Requirements and proxy configuration, see [Troubleshooting & Support](/authentication/windows-workstation-mfa/troubleshooting-and-support). *** #### Step 3 - Test Login with MFA Perform a test login using a user account that has an Adaptive Auth Journey configured in AdminX. 1. On the Windows login screen, click the **1Kosmos** tile. 2. If prompted, enter the username. 3. Complete the configured authentication method (e.g., enter password then approve push notification). 4. Confirm the user is successfully logged into Windows. If the test fails, check the following: * The user exists in the connected Active Directory or LDAP directory. * An Adaptive Auth Journey is configured for the user or their AD group under **Applications > Windows MFA** in AdminX. * The user has the required authentication method enrolled (e.g., 1Kosmos mobile app linked for Push / TOTP; 1Key enrolled for FIDO). * Check log files at `C:\Program Files\1Kosmos\BlockIDCredentialProvider\Logs` for error details. * See **Troubleshooting** for common failure scenarios. {% hint style="info" %} Always test with a non-administrator account first. Local administrator accounts bypass 1Kosmos MFA by design — a successful local admin login does not confirm the agent is working correctly. {% endhint %} # Authentication Methods The Windows Workstation MFA Agent supports multiple authentication methods. The method presented to a user at login is determined by the Adaptive Auth Journey configured for them in AdminX. *** ### Available Authentication Methods | Method | Requires Mobile App | Works Offline | Minimum Version | | ----------------------------- | ------------------- | -------------------- | --------------- | | Password + OTP | ✅ (for OTP) | ✅ (Account OTP only) | All versions | | Push Notification | ✅ | ❌ | All versions | | QR Code | ✅ | ❌ | All versions | | FIDO / 1Key | ❌ | ❌ | All versions | | SMS / Email / Voice OTP | ❌ | ❌ | v2.0.6.0+ | | Behavior Authentication + PIN | ❌ | ✅ (cached PIN) | v2.1.2.0+ | | Run As / UAC Elevation | Depends on method | ✅ | All versions | {% hint style="info" %} **Note:** The methods available to a user at login depend entirely on the Adaptive Auth Journey configured for them in AdminX. A method listed here will not appear at login unless it is configured in a journey. {% endhint %} # Password + OTP Users authenticate by entering their Active Directory password followed by a one-time passcode. This is the most common MFA configuration for organisations transitioning away from password-only login.
Password + OTP Login user Journey
*** ### Admin Setup Before users can authenticate with Password + OTP, configure an Adaptive Auth Journey in AdminX. 1. Log in to AdminX as a community administrator. 2. Navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 3. Click **Add new adaptive auth journey**. 4. Provide a journey name and define conditions (by user, group, or machine name). 5. Set the Action to **MFA Required**. 6. Select one of the following authentication methods depending on which OTP source you want to allow: | Method | OTP Source | | ---------------------------- | ------------------------------------------- | | Password & any OTP | 1Kosmos app TOTP, SMS, Email, or Voice call | | Password & 1Kosmos App Codes | 1Kosmos mobile app TOTP only | | Password & SMS OTP | SMS to registered mobile number | | Password & Email OTP | Email to registered email address | | Password & Voice OTP | Voice call to registered phone number | 7. Click **Save**. {% hint style="info" %} For SMS, Email, and Voice OTP, the user's phone number or email address must be present on their Active Directory profile. If the attribute is missing, the option will not be presented to the user at login. {% endhint %} #### User Guide — Logging in with Password + OTP 1. On the Windows login screen, click the **1Kosmos** tile. 2. If using the **Other User** tile, enter your username and click **Submit**. 3. On the **Choose an authentication method** screen, click **Password**. 4. Enter your Active Directory password and click the arrow to proceed. 5. On the **Enter your verification code** screen, enter the OTP from your chosen source: * **1Kosmos app** — open the app and use the TOTP code displayed * **SMS** — click **Send Code via SMS** and enter the code received * **Email** — click **Send Code via Email** and enter the code received * **Voice** — click **Send Code via Call** and enter the code received 6. Press **Enter**. You will be logged into Windows. {% hint style="info" %} If you enter an incorrect OTP more than the maximum number of attempts configured by your administrator, your account will be locked. Contact your help desk to unlock it. {% endhint %} #### Troubleshooting | Issue | Likely Cause | Resolution | | ---------------------------------------- | ------------------------------------------------------------- | --------------------------------------------- | | OTP option not appearing at login | No journey configured, or journey does not include OTP method | Check AdminX auth journey configuration | | SMS / Email / Voice option not appearing | Phone number or email not on AD profile | Add the attribute to the user's AD profile | | OTP code rejected | Code expired (TOTP codes are time-sensitive) | Generate a new code and try again immediately | | Account locked after failed attempts | Max OTP attempts exceeded | Contact help desk to unlock | # Push Notification Users receive an approval request on the 1Kosmos mobile app. From v2.0.4.0, a Number Challenge option is available to protect against push bombing attacks.
Push notification login user Journey
*** ### Admin Setup #### Configure the Authentication Journey 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Create a new journey or edit an existing one. 3. Under **Authentication Method**, select either: * **Push Notification** - push-only, no password required. * **Password & Push Notification** - password entered first, then push sent. 4. Assign the journey to the target user group or machine policy. 5. Save and publish the journey. #### Enable Number Challenge {% hint style="info" %} Number Challenge requires Credential Provider v2.0.4.0 or later. Ensure the agent is updated before enabling this toggle. {% endhint %} 1. In AdminX, navigate to **Authentication > Passwordless Login > Passwordless Login using 1Kosmos App**. 2. Toggle **Enable number challenge on all push notification requests** to **ON**. 3. Save the settings. When enabled, all push notifications sent through any journey configured with Push Notification will include a number challenge. *** ### User Guide #### Standard Push Notification Login 1. At the Windows login screen, click the **1Kosmos** tile. 2. If using the **Other User** tile, enter your username first. 3. Select **Push Notification** from the available authentication options. 4. A push notification is sent to your enrolled 1Kosmos mobile app. 5. Open the notification and tap **Yes, it's me**. 6. The Windows session unlocks and you are logged in. {% hint style="info" %} The push notification expires after a fixed timeout. If not approved in time, the request cancels and you must initiate a new login attempt. {% endhint %} #### Push Notification with Number Challenge 1. At the Windows login screen, click the **1Kosmos** tile. 2. If using the **Other User** tile, enter your username first. 3. Select **Push Notification** from the available authentication options. 4. A number is displayed on the Windows login screen. 5. A push notification is sent to your enrolled 1Kosmos mobile app showing multiple numbers. 6. In the app, tap the number that matches the number shown on the Windows screen. 7. If the correct number is selected, the Windows session unlocks and you are logged in. {% hint style="warning" %} If you tap the wrong number, the authentication attempt is immediately cancelled. You must return to the Windows login screen and initiate a new login attempt. Repeated wrong selections may indicate a push bombing attack — do not approve any push you did not personally initiate. {% endhint %} ### Behavior Comparison | Behavior | Number Challenge Disabled | Number Challenge Enabled | | --------------------------------- | ----------------------------- | ---------------------------------------------- | | Interface on Windows login screen | No number displayed | A number is shown on screen | | Interface on mobile app | "Yes, it's me" consent screen | Number selection screen with multiple options | | Required user action | Tap **Yes, it's me** | Tap the number matching the Windows screen | | Protection against push bombing | Not provided | Active - wrong number cancels auth immediately | *** ### Troubleshooting | Issue | Likely Cause | Resolution | | ---------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Push notification not received | Mobile app not enrolled or disconnected; no device internet; OS notifications blocked | Verify mobile app is enrolled and connected; check device internet and notification permissions; ask user to open the app manually and check pending requests | | Push notification expired | User did not respond within the timeout window | Initiate a new login attempt from the Windows login screen | | Wrong number selected (Number Challenge) | User tapped incorrect number | Authentication is automatically cancelled; initiate a new login attempt; if recurring, verify no push bombing attempt is in progress | | User tapped Cancel | User dismissed the notification intentionally or accidentally | Initiate a new login attempt; if recurring, check for unsolicited push notifications and report as a potential push bombing incident | | Push received but app shows error | App version outdated; tenant connectivity issue | Update the 1Kosmos mobile app; verify tenant URL and connectivity from the mobile device | # QR code Users scan a QR code displayed on the Windows login screen using the 1Kosmos mobile app. No password is required when QR is configured as the sole authentication method.
QR Code login user Journey
*** ### Admin Setup #### Configure the Authentication Journey {% stepper %} {% step %} In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. {% endstep %} {% step %} Create a new journey or edit an existing one. {% endstep %} {% step %} Under **Authentication Method**, select **QR Code**. * To use QR as the sole authentication factor (passwordless), select **QR Code** only. * To combine with a password, select **Password & QR Code**. {% hint style="info" %} When QR is configured as the sole factor, users are not prompted for a password at any point in the login flow. Ensure your organisation's security policy permits passwordless authentication before enabling this configuration. {% endhint %} {% endstep %} {% step %} Assign the journey to the target user group or machine policy. {% endstep %} {% step %} Save and publish the journey. {% endstep %} {% endstepper %} ### User Guide #### Login from the User Tile {% stepper %} {% step %} At the Windows login screen, click the **1Kosmos** tile. {% endstep %} {% step %} Select **QR Code** from the available authentication options. {% endstep %} {% step %} A QR code is displayed on the Windows login screen. {% endstep %} {% step %} Open the 1Kosmos mobile app and use the QR scanner to scan the code. {% endstep %} {% step %} The app confirms the scan and sends an approval to the Credential Provider. {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% endstepper %} {% hint style="info" %} The QR code expires after a fixed timeout. If it expires before scanning, click **Refresh** to generate a new code. {% endhint %} #### Login from the Other User Tile {% stepper %} {% step %} At the Windows login screen, click **Other User**. {% endstep %} {% step %} Enter your Windows username and press **Enter**. {% endstep %} {% step %} A QR code is displayed automatically, no further input is required on the Windows side. {% endstep %} {% step %} Open the 1Kosmos mobile app and use the QR scanner to scan the code. {% endstep %} {% step %} The app confirms the scan and sends an approval to the Credential Provider. {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% endstepper %} {% hint style="info" %} When using the Other User tile, any persona enrolled in the 1Kosmos mobile app can scan the QR code. The authentication context is tied to the username entered on the Windows side, not the mobile persona performing the scan. Ensure the correct username is entered before the QR code is presented. {% endhint %} ### Troubleshooting | Issue | Likely Cause | Resolution | | ---------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | QR code not scanning | Camera obstructed; QR code too small on screen; poor lighting | Clean the device camera lens; increase display brightness; move closer to the screen; try scanning from a different angle | | QR code expired before scanning | User took too long to initiate the scan | Click **Refresh** on the Windows login screen to generate a new QR code and scan immediately | | Camera permission denied on mobile | The 1Kosmos app does not have camera access | On the mobile device, go to **Settings > Apps > 1Kosmos** and enable **Camera** permission, then retry | | QR scanned but no login response | Mobile app lost connectivity after scanning | Verify the mobile device has an active internet connection; retry the login flow | | QR code screen does not appear | Journey not configured with QR method; agent not running | Verify the assigned Adaptive Auth Journey includes QR Code as the authentication method; confirm the Credential Provider service is running on the workstation | # LiveID Selfie Configure LiveID Selfie with Push Notification for Windows login in 1Kosmos. Authenticate using facial biometrics and 1Kosmos app approval. Users provide a live selfie on a camera-enabled device at the Windows login screen. Facial recognition and liveness detection verify the user is physically present. No password is required when LiveID Selfie is configured as the sole authentication method.
### Admin Setup #### Configure the Authentication Journey 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Create a new journey or edit an existing one. 3. Under **Authentication Method**, select **LiveID Selfie**. 4. To use LiveID Selfie as the sole authentication factor (passwordless), select **LiveID Selfie only**. To combine with a password, select **Password & LiveID Selfie**. 5. When LiveID Selfie is configured as the sole factor, users are not prompted for a password at any point in the login flow. Ensure your organisation's security policy permits passwordless authentication before enabling this configuration. 6. Assign the journey to the target user group or machine policy. 7. Save and publish the journey. #### Auth Type Configuration You can configure how the user is prompted for a PIN after a LiveID Selfie capture by setting the `authType`. This also controls PIN prompts based on whether the device is trusted. | Value | Description | | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `none` | Users are never prompted for a PIN. | | `pin` | Users are always prompted for a PIN. | | `auto` | Users are prompted for a PIN only on new devices or untrusted devices. Once a device is marked as trusted, subsequent logins require only the selfie. | ### User Guide #### Login from the User Tile 1. At the Windows login screen, click the **1Kosmos tile**. 2. Select **LiveID Selfie** from the available authentication options. 3. Position your face within the oval shown on the screen. When aligned properly, the selfie is captured automatically. 4. Enter your LiveID Selfie PIN. To skip the PIN prompt on future logins from this device, select **Trust this device**. 5. After successful authentication, you are logged into the workstation. {% hint style="info" %} If you selected **Trust this device**, subsequent logins from this device require only the selfie — no PIN prompt. {% endhint %} #### Login from the Other User Tile 1. At the Windows login screen, click **Other User**. 2. Enter your Windows username and press **Enter**. 3. Select **LiveID Selfie** from the available authentication options. 4. Position your face within the oval shown on the screen. When aligned properly, the selfie is captured automatically. 5. Enter your LiveID Selfie PIN. To skip the PIN prompt on future logins from this device, select **Trust this device**. 6. After successful authentication, you are logged into the workstation. *** ## LiveID Selfie & Push Notification Users provide a live selfie on a camera-enabled device and approve the sign-in request via the 1Kosmos mobile app. No password is required when LiveID Selfie & Push Notification is configured as the sole authentication method. ### Admin Setup #### Configure the Authentication Journey 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Create a new journey or edit an existing one. 3. Under **Authentication Method**, select **LiveID Selfie & Push Notification**. 4. To use this as the sole authentication factor (passwordless), select **LiveID Selfie & Push Notification only**. To combine with a password, select **Password & LiveID Selfie & Push Notification**. 5. When configured as the sole factor, users are not prompted for a password at any point in the login flow. Ensure your organisation's security policy permits passwordless authentication before enabling this configuration. 6. Assign the journey to the target user group or machine policy. 7. Save and publish the journey. #### Auth Type Configuration You can configure how the user is prompted for a PIN after a LiveID Selfie capture by setting the `authType`. This also controls PIN prompts based on whether the device is trusted. | Value | Description | | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `none` | Users are never prompted for a PIN. | | `pin` | Users are always prompted for a PIN. | | `auto` | Users are prompted for a PIN only on new devices or untrusted devices. Once a device is marked as trusted, subsequent logins require only the selfie and push approval. | ### User Guide #### Login from the User Tile 1. At the Windows login screen, click the **1Kosmos tile**. 2. Select **LiveID Selfie** from the available authentication options. 3. Position your face within the oval shown on the screen. When aligned properly, the selfie is captured automatically. 4. Enter your LiveID Selfie PIN. To skip the PIN prompt on future logins from this device, select **Trust this device**. 5. A push notification is sent to your 1Kosmos mobile app. Open the app and approve the sign-in request. 6. After successful authentication, you are logged into the workstation. {% hint style="info" %} If you selected **Trust this device**, subsequent logins from this device require only the selfie and push approval no PIN prompt. {% endhint %} #### Login from the Other User Tile 1. At the Windows login screen, click **Other User**. 2. Enter your Windows username and press **Enter**. 3. Select **LiveID Selfie** from the available authentication options. 4. Position your face within the oval shown on the screen. When aligned properly, the selfie is captured automatically. 5. Enter your LiveID Selfie PIN. To skip the PIN prompt on future logins from this device, select **Trust this device**. 6. A push notification is sent to your 1Kosmos mobile app. Open the app and approve the sign-in request. 7. After successful authentication, you are logged into the workstation. # 1Key Biometric Users authenticate using a FIDO2 hardware security key. 1Kosmos supports both single-user keys and multi-user biometric keys (1Key Desktop, which supports up to 3 enrolled users per key). *** ### Admin Setup **Configure the Journey for Standard FIDO Login** {% stepper %} {% step %} In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. {% endstep %} {% step %} Create a new journey or edit an existing one. {% endstep %} {% step %} Under **Authentication Method**, select **FIDO**. {% endstep %} {% step %} Assign the journey to the target user group or machine policy. {% endstep %} {% step %} Save and publish the journey. {% endstep %} {% endstepper %} ### **Configure the Journey for Shared Account Login (CyberArk)** {% stepper %} {% step %} In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. {% endstep %} {% step %} Create a new journey or edit an existing one. {% endstep %} {% step %} Under **Authentication Method**, select **FIDO for Shared Account Login**. {% endstep %} {% step %} Configure the CyberArk integration settings as required by your deployment. {% endstep %} {% step %} Assign the journey to the target shared account user group. {% endstep %} {% step %} Save and publish the journey. {% endstep %} {% endstepper %} {% hint style="info" %} Before any user can authenticate with a FIDO2 key or 1Key, the key must be enrolled in the 1Kosmos platform. See [1Key Enrollment Documentation ](/authentication/1key-biometric/overview)for enrollment steps. Non-enrolled keys will not be recognised during authentication. {% endhint %} ### User Guide **Login with a Single-User FIDO2 Key** {% stepper %} {% step %} Plug the FIDO2 security key into a USB port on the workstation. {% endstep %} {% step %} At the Windows login screen, click the **1Kosmos** tile. {% endstep %} {% step %} If using the **Other User** tile, enter your username first. {% endstep %} {% step %} Click **Security Key**. {% endstep %} {% step %} Place your enrolled finger on the key's fingerprint sensor. * For biometric keys (such as 1Key), a PIN prompt is **not** presented, fingerprint is the sole authenticator on the key. * For non-biometric FIDO2 keys, a PIN entry prompt appears. Enter the key PIN, then touch the key when it blinks. {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% endstepper %} {% hint style="info" %} If fingerprint recognition fails after multiple attempts, clean the sensor surface with a dry cloth and retry. See [Troubleshooting](#troubleshooting) below for further guidance. {% endhint %} ### **Login with a Multi-User Key / 1Key Desktop** The 1Key Desktop is a desk-mounted biometric key that supports up to 3 enrolled user profiles per device. {% stepper %} {% step %} Approach the workstation, the 1Key Desktop sensor is mounted on or near the desk. {% endstep %} {% step %} Long-press the sensor to cycle through and select your enrolled user profile. {% endstep %} {% step %} When your profile indicator is active, place your finger on the sensor. {% endstep %} {% step %} Authentication is processed and the Windows session unlocks. {% endstep %} {% endstepper %} {% hint style="info" %} If multiple users share the same workstation, ensure each user has enrolled their profile on the specific 1Key Desktop unit assigned to that workstation. Profile enrollment is device-specific. {% endhint %} ### **Shared Account Login with 1Key (CyberArk Integration)** {% stepper %} {% step %} Plug the 1Key into a USB port or approach the 1Key Desktop unit. {% endstep %} {% step %} At the Windows login screen, click the **1Kosmos** tile. {% endstep %} {% step %} Authenticate your primary identity using the 1Key (fingerprint, as described above). {% endstep %} {% step %} A list of shared accounts you are authorised to access is displayed. {% endstep %} {% step %} Select the target shared account from the list. {% endstep %} {% step %} The Windows session launches under the selected shared account. {% endstep %} {% endstepper %} {% hint style="info" %} The list of authorised shared accounts is sourced from CyberArk based on your primary identity's permissions. If expected accounts do not appear, verify your CyberArk entitlements with your privileged access administrator. {% endhint %} ### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Key not recognised by Windows | USB port issue; driver not loaded; key not enrolled | Try a different USB port; verify the Credential Provider service is running; confirm the key is enrolled in the 1Kosmos platform | | Fingerprint not recognised | Sensor surface dirty; enrolled finger not placed correctly; skin condition affecting read | Clean the sensor with a dry, lint-free cloth; ensure the full enrolled finger pad covers the sensor; re-enroll the fingerprint if the issue persists | | Wrong user profile selected on 1Key Desktop | Incorrect profile activated via long-press | Long-press the sensor again to cycle back to the correct user profile before placing the finger | | Shared account not appearing after authentication | CyberArk entitlement not granted; CyberArk integration misconfigured; journey not set to Shared Account Login | Verify CyberArk account permissions for the authenticated user; confirm the journey uses the FIDO for Shared Account Login method; contact your PAM administrator | | PIN prompted for biometric key | Key firmware or enrollment issue | Biometric 1Key keys should not prompt for PIN; re-enroll the fingerprint via the 1Key management tool; contact 1Kosmos support if the issue persists | # SMS, Email, Voice, OTP Available from v2.0.6.0. Users receive a one-time passcode via SMS, email, or voice call. No mobile app installation is required. *** ### Admin Setup **Configure the Authentication Journey** {% stepper %} {% step %} In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. {% endstep %} {% step %} Create a new journey or edit an existing one. {% endstep %} {% step %} Under **Authentication Method**, select **Any OTP**. {% endstep %} {% step %} Assign the journey to the target user group or machine policy. {% endstep %} {% step %} Save and publish the journey. {% endstep %} {% endstepper %} ### **Prerequisite: AD Profile Attributes** The delivery options presented to a user depend on the attributes populated on their Active Directory profile. The phone number and email address fields must be populated before the user attempts to log in. | If the user has registered | Options shown on login screen | | ------------------------------------ | ----------------------------------------------------------------------- | | Email address only | Send Code via Email | | Mobile number only | Send Code via SMS, Send Code via Call | | Both email address and mobile number | Send Code via Email, Send Code via SMS, Send Code via Call | | Neither | No OTP delivery options shown — user cannot complete OTP authentication | {% hint style="info" %} The user can also enter a TOTP code from the 1Kosmos mobile app directly without selecting any of the delivery method options above. The TOTP input field is available regardless of AD attribute configuration. {% endhint %} *** ### User Guide **SMS / Email / Voice OTP Login** {% stepper %} {% step %} At the Windows login screen, click the **1Kosmos** tile. {% endstep %} {% step %} If using the **Other User** tile, enter your username first. {% endstep %} {% step %} Enter your Windows password when prompted. {% endstep %} {% step %} On the verification code screen, select your preferred delivery method: * **Send Code via Email** * **Send Code via SMS** * **Send Code via Call** {% endstep %} {% step %} Retrieve the one-time passcode from your email inbox, SMS message, or voice call. {% endstep %} {% step %} Enter the passcode in the code input field on the Windows login screen. {% endstep %} {% step %} Click **Verify** (or press **Enter**). {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% endstepper %} {% hint style="warning" %} If you enter an incorrect OTP more than the permitted number of times, your account will be locked. Contact your helpdesk to unlock the account. Do not repeatedly attempt to guess a code. {% endhint %} *** ### Troubleshooting | Issue | Likely Cause | Resolution | | ----------------------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | SMS, Email, or Voice option not appearing | The corresponding attribute (mobile number or email) is not populated on the user's AD profile | Populate the `mobile` and/or `mail` attribute on the user's AD account and retry; contact your AD administrator if you do not have access | | Code not received via SMS or Voice | Incorrect mobile number on AD profile; carrier delay; network issue | Verify the mobile number on the AD profile is correct and in E.164 format; wait up to 60 seconds and retry; try an alternative delivery method if available | | Code not received via Email | Incorrect email on AD profile; email filtered to spam/junk | Verify the email address on the AD profile; check spam/junk folders; try an alternative delivery method if available | | Code entered but rejected | OTP expired before entry; code typed incorrectly | Request a new code and enter it promptly; ensure no transcription errors; note that OTP codes are case-sensitive if alphanumeric | | Account locked after failed OTP attempts | Maximum incorrect OTP attempts exceeded | Contact the helpdesk to unlock the account; do not retry until the account is unlocked | | No delivery options shown at all | Neither mobile number nor email is on the AD profile | Contact your AD administrator to populate the required attributes before retrying | # Behavior Authentication Users authenticate by typing a displayed phrase (typing biometrics) followed by a PIN. No mobile app or hardware key required. Supports offline authentication via cached PIN.
Behavior Authentication User journey
*** ### Overview Behavioral Authentication is particularly useful in environments requiring complex passwords (14–16 characters for PCI DSS compliance). With Behavioral Authentication and PIN enrolled, users can log in without repeatedly typing long passwords. Both factors are enrolled and used via the **Windows Workstation MFA Agent**. ### Credential Provider Both factors are enrolled and used via the Windows Workstation MFA Agent. #### **Admin Setup** **Enabling Behavior Auth and PIN Enrollment** Both PIN Enrollment and Behavior Auth Enrollment are disabled by default and must be explicitly enabled before users can enroll or authenticate with this method. 1. In AdminX, navigate to **Applications > Windows MFA > Settings > Enrollment Preferences**. 2. Toggle PIN Enrollment to ON. 3. Toggle Behavior Auth Enrollment to ON. 4. Save the settings. Users will not see enrollment prompts or Behavior Auth login options until both toggles are enabled. **Configuring the Authentication Journey** 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Create a new journey or edit an existing one. 3. Under Authentication Method, select **Behavior Auth & PIN**. 4. Assign the journey to the target user group or machine policy. 5. Save and publish the journey. *** ### AdminX Behavior Authentication is now also supported for AdminX login. Administrators can configure it as an adaptive authentication method and enroll their typing pattern directly from their AdminX profile. **Admin Setup** Configuring Behavior Auth in Adaptive Authentication 1. Log in to AdminX as a community admin. 2. Navigate to **Authentication > Adaptive Authentication**. 3. Click Add new adaptive auth journey. 4. Enter a Journey Name and ensure the Enabled toggle is ON. 5. Set the Conditions as required (for example, restrict by application or username). 6. Under Decision, set Action to MFA Required. 7. From the authentication method list, select Behavior Auth & PIN, *Prompts the user to log in with their typing pattern and PIN.* 8. Click **Save**. **Enrolling Behavior Auth and PIN** Administrators enroll their typing pattern directly from their AdminX profile. 1. Navigate to **My Profile > Login Options**. 2. Click the **Setup** dropdown and select **Typing Pattern**. 3. On the Setup Behavior Authentication screen, click **Continue to enroll**. 4. On the **Capture Typing Pattern** screen, type the displayed phrase exactly as shown in the Your input field — type naturally, as the system captures your rhythm. 5. Complete all 5 attempts and click **Finish enrollment**. 6. The enrolled Typing Pattern appears under **Login Options**. {% hint style="info" %} PIN enrollment is a separate step. If PIN is not yet enrolled, select Pin from the Setup dropdown and complete PIN enrollment before using Behavior Auth & PIN to log in. {% endhint %} **Logging in to AdminX** 1. On the AdminX Sign in screen, select the **Username** tab. 2. Enter your Corporate Username and click Next. 3. On the **Capture Typing Pattern** screen, type the displayed phrase exactly as shown in the Your input field and click **Next**. 4. On the **Enter your PIN** screen, enter your 4-digit PIN and click Submit. 5. You are signed in to the AdminX interface. {% hint style="info" %} The typing pattern screen appears only if Behavior Auth & PIN is configured as the authentication method in the adaptive auth journey assigned to your account. If you are not prompted for a typing pattern, verify the journey configuration with your administrator. {% endhint %} **Configuring Fallback Authentication (v2.2.0.0+)** Fallback authentication allows a helpdesk-generated passcode to be used when a user cannot complete Behavior Auth & PIN after repeated failures. {% stepper %} {% step %} In AdminX, navigate to **Applications > Windows MFA > Settings > Authentication Preferences**. {% endstep %} {% step %} Enable the **Fallback Journeys** slider. {% endstep %} {% step %} Set the **Trigger fallback after number of attempts** value to the desired threshold. {% endstep %} {% step %} Create or select a separate Adaptive Auth Journey with the **Admin Passcode** authentication method. {% endstep %} {% step %} Assign this journey as the **Fallback Auth Journey**. {% endstep %} {% step %} Save the settings. {% endstep %} {% endstepper %} To generate a helpdesk passcode for a specific user: {% stepper %} {% step %} In AdminX, navigate to **Users > All Users**. {% endstep %} {% step %} Locate the user and click the **three-dot menu** next to their name. {% endstep %} {% step %} Select **Generate Passcode**. {% endstep %} {% step %} Set the passcode expiry (range: 1 minute to 24 hours; default: 10 minutes). {% endstep %} {% step %} Provide the generated passcode to the user via a secure out-of-band channel. {% endstep %} {% endstepper %} *** ### Enrollment Enrollment is triggered automatically on the user's first login after Behavior Auth is enabled. Users cannot be pre-enrolled by an administrator. {% stepper %} {% step %} The user completes their normal authentication flow (e.g., password + OTP) as usual. {% endstep %} {% step %} After successful primary authentication, the enrollment prompt appears. {% endstep %} {% step %} A phrase is displayed on screen. The user types the phrase the configured number of times. Each entry captures the user's natural typing rhythm and cadence. Enrollment is complete when the required number of samples have been accepted. {% endstep %} {% step %} The user is prompted to create a PIN. PIN length and complexity requirements are determined by the organisation's policy configured in AdminX. The user enters the PIN twice to confirm. {% endstep %} {% step %} Enrollment is saved to the user's profile. {% endstep %} {% endstepper %} {% hint style="info" %} Users can click **Skip** to bypass enrollment and log in normally. They will be prompted to enroll again on the next login attempt. Enrollment cannot be permanently skipped — the prompt recurs until enrollment is completed. {% endhint %} ### User Guide **Standard Login with Behavior Auth & PIN** {% stepper %} {% step %} At the Windows login screen, click the **1Kosmos** tile. {% endstep %} {% step %} If using the **Other User** tile, enter your username first. {% endstep %} {% step %} Select **Behavior Auth** from the available authentication options. {% endstep %} {% step %} A phrase is displayed on screen. Type the phrase naturally, do not alter your typing speed or style. {% endstep %} {% step %} After the phrase is accepted, enter your PIN. {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% endstepper %} **Offline Login with Cached PIN** When the workstation has no network connectivity, the Credential Provider detects the offline state and presents available offline options. {% stepper %} {% step %} At the Windows login screen, click the **1Kosmos** tile. {% endstep %} {% step %} The Credential Provider detects no connectivity and displays offline authentication options. {% endstep %} {% step %} Select **PIN**. {% endstep %} {% step %} Enter your PIN. {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% endstepper %} {% hint style="warning" %} Offline PIN authentication is limited to **3 attempts**. After 3 failed attempts, the cached PIN is cleared and offline PIN login is no longer available until the device reconnects and the user re-authenticates online. Contact your helpdesk if the cached PIN has been cleared. {% endhint %} **Fallback Login (Helpdesk Passcode)** {% stepper %} {% step %} After exceeding the configured number of failed Behavior Auth & PIN attempts, the **Trouble Logging In?** screen appears. {% endstep %} {% step %} Click **Helpdesk Code**. {% endstep %} {% step %} Contact your helpdesk and request a one-time passcode. {% endstep %} {% step %} Enter the passcode provided by the helpdesk. {% endstep %} {% step %} The Windows session unlocks and you are logged in. {% endstep %} {% step %} Optionally, you will be prompted to reset your enrolled typing pattern and/or PIN after logging in via fallback. {% endstep %} {% endstepper %} **Managing Enrolled Pattern and PIN** Users can view, modify, or delete their enrolled typing pattern and PIN via the AdminX self-service portal. {% stepper %} {% step %} Log in to AdminX. {% endstep %} {% step %} Navigate to **My Profile > Login Options**. {% endstep %} {% step %} Select the **Behavior Auth** or **PIN** entry. {% endstep %} {% step %} Choose to **Modify** or **Delete** the enrolled factor as required. {% endstep %} {% endstepper %} {% hint style="info" %} Deleting an enrolled factor will require re-enrollment at the next login attempt. {% endhint %} ### Best Practices **Typing Biometrics, Do's and Don'ts** | Do | Don't | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Type naturally, at your normal pace | Don't intentionally slow down or speed up while typing | | Use the same device and keyboard you enrolled on | Don't frequently switch keyboards between enrollment and authentication | | Type in lowercase as prompted | Don't type in uppercase or mix case unless instructed | | Complete enrollment carefully, multiple samples improve accuracy | Don't rush through the enrollment phrase entries | | Perform enrollment in a normal working environment | Don't let another person type on your behalf during enrollment or authentication | ### Troubleshooting | Issue | Likely Cause | Resolution | | -------------------------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Typing pattern not recognised | User's typing style has changed; different keyboard used; typing too fast or too slow | Type naturally and at a consistent pace; ensure you are using the same keyboard as during enrollment; if repeated failures occur, proceed through the fallback flow and re-enroll | | PIN forgotten | User cannot recall their PIN | Use the fallback authentication flow (Helpdesk Code) to log in, then reset the PIN via **My Profile > Login Options** in AdminX | | Account locked after failed Behavior Auth attempts | Maximum failed attempts exceeded before fallback threshold triggered | Contact the helpdesk to unlock the account and obtain a fallback passcode | | Offline PIN cleared after 3 failed attempts | Three consecutive incorrect PIN entries in offline mode | Reconnect the device to the network; log in online to re-establish the cached PIN | | Enrollment prompt not appearing | Behavior Auth Enrollment or PIN Enrollment toggle is OFF in AdminX | Verify both toggles are enabled in **Applications > Windows MFA > Settings > Enrollment Preferences** | | Fallback option not available | Fallback Journeys slider is OFF; fallback journey not configured | Enable the Fallback Journeys slider and assign a fallback journey with the Admin Passcode method in Authentication Preferences | # Fallback Authentication Configure a secure fallback authentication method for Windows login so users can regain access with a Helpdesk-issued one-time passcode when their primary method fails. *** ### Overview When users sign in to Windows, authentication is typically performed using their primary authentication method. However, in certain situations, users may be unable to authenticate successfully. For example: * Behavioral Authentication may fail due to changes in the user's typing patterns. * A user may forget their PIN. To prevent unnecessary workstation lockouts, 1Kosmos provides a configurable fallback authentication mechanism for Windows login. This feature allows administrators to define a secure secondary authentication method that users can use when the primary method fails. In such cases, users can contact the Helpdesk to obtain a temporary one-time passcode (OTP). The OTP allows the user to securely sign in to Windows and reset one enrolled authentication factor, such as Behavioral Authentication or PIN. {% hint style="info" %} The fallback authentication mechanism is currently supported only for users enrolled in Behavioral Authentication and PIN authentication methods. Users must have previously enrolled in one or both of these methods to use fallback authentication. {% endhint %} ### How It Works Community Administrators can configure a fallback auth journey within the AdminX interface as part of the Windows MFA Fallback Authentication Journeys. As part of this configuration: * Passcodes are enabled as an authentication factor. * Community Administrators, or users with the **user.helpdesk-passcode.generate** permission , can generate a passcode from a user's profile. * The user can authenticate their Windows workstation using the passcode and then reset the failed authentication factor in the 1Kosmos Credential Provider before logging in. The fallback authentication process consists of three key stages that enable secure account recovery for users locked out due to behavioral authentication failure: * [Setting up Fallback Authentication](#step-1-setting-up-fallback-authentication) * [User login experience when fallback is triggered](#step-2-user-login-experience-when-fallback-is-triggered) * [Generating passcodes](#step-3-generating-passcodes) ### Step 1: Setting Up Fallback Authentication This step involves enabling the Fallback Authentication Journeys tab in the AdminX interface and configuring the fallback authentication workflow. #### Enabling the Display of Fallback Auth Journeys Tab on AdminX Interface To display the Fallback Auth Journeys tab: {% stepper %} {% step %} #### Log in Log in to your tenant as a community administrator. {% endstep %} {% step %} #### Open Windows MFA settings Navigate to **Applications > Windows MFA > Settings**. {% endstep %} {% step %} #### Go to Authentication Preferences Go to the **Authentication Preferences** section. {% endstep %} {% step %} #### Turn on Fallback Journeys Turn the **Fallback Journeys** slider ON. By default, the slider is turned off. {% endstep %} {% step %} #### Set the trigger threshold In the **Trigger fallback after number of attempts** field that appears after turning the slider ON, specify the number of attempts after which the fallback journey is triggered once a user has failed the auth attempts that many times. {% endstep %} {% step %} #### Save Click **Save**. {% endstep %} {% endstepper %} ### Configuring Fallback Auth Journeys Community administrators can use the Fallback Auth journeys tab to configure a fallback journey and define the authentication method to be used for that journey. To configure a fallback auth journey: 1. Log in to your tenant as a community administrator. 2. Navigate to **Applications > Windows MFA**. The Windows MFA page is displayed. 3. Click the **Fallback Auth journeys** tab. 4. To add a new journey, click **Add new fallback journey**. 5. In the page that is displayed, provide the following details: a. Provide a descriptive name for the journey. b. Define Conditions from the following options. | Condition | Operator | Description | | ------------ | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Groups | is one of | Select this option to apply the journey only to specific AD groups. You can choose from a list of predefined groups, and the journey will apply only if the AD group exactly matches one of those. | | Groups | is not one of | The journey applies to all other groups except for the ones mentioned. | | Groups | contains | Select this option if you want the journey to apply to any AD group whose name includes a specific keyword or phrase. | | Groups | does not contain | Select this option to apply the journey for all other groups that do not include the specified keyword or phrases. | | Username | is one of | Specify the list of users for whom this journey is applicable. | | Username | is not one of | The journey applies to all other users except for the ones mentioned. | | Username | contains | Select this option if you want the journey to apply to any user whose name includes a specific keyword or phrase. | | Username | does not contain | Select this option to apply the journey for all other usernames that do not include the specified keywords or phrases. | | Username | starts with | Select this option to apply the journey for usernames that begin with the specified characters or words. | | Username | does not start with | Select this option to apply the journey for all other usernames that do not begin with the specified characters or words. | | Username | ends with | Select this option to apply the journey for users whose names end with specified characters or words. | | Username | does not end with | Select this option to apply the journey for all other usernames that do not end with the specified characters or words. | | Machine Name | is one of | Specify the machine name to which this journey has to be applied. | | Machine Name | is not one of | The journey applies to all other machines except for the ones mentioned. | c. Define the outcome for each condition. You can select the "MFA Required" action for a journey. The following table provides the supported authentication methods for the above actions: | Authentication Method | Description | | --------------------- | -------------------------------------------------- | | Admin Passcode | Prompts users to enter a passcode to authenticate. | d. Click **Save**. You can disable a fallback authentication journey by editing the journey and disabling the slider beside the journey name. ### Editing Fallback Auth Journey Community administrators can modify or update the fallback auth journey in the AdminX interface. To modify the auth journey: {% stepper %} {% step %} #### Log in Log in to your tenant as a community administrator. {% endstep %} {% step %} #### Open Windows MFA Navigate to **Applications > Windows MFA**. {% endstep %} {% step %} #### Find the journey In the **Fallback Auth Journeys** page that is displayed, navigate to the journey that you want to modify. {% endstep %} {% step %} #### Edit the journey Under the **Actions** column, click the pencil icon in line with the row that you want to edit. {% endstep %} {% step %} #### Save changes Modify the required details and click **Save**. {% endstep %} {% step %} #### Deleting Fallback Auth Journey Community administrators can use the AdminX interface to delete a fallback auth journey. To delete a fallback auth journey: {% endstep %} {% step %} #### Log in Log in to your tenant as a community administrator. {% endstep %} {% step %} #### Open Windows MFA Navigate to **Applications > Windows MFA**. {% endstep %} {% step %} #### Find the journey In the **Fallback Auth Journeys** page that is displayed, navigate to the journey that you want to delete. {% endstep %} {% step %} #### Delete the journey Click the Delete icon beside the journey that you want to delete. The auth journey is deleted. {% endstep %} {% endstepper %} ### Step 2: User Login Experience when Fallback is Triggered This section describes the user's login flow when fallback authentication is triggered due to behavioral authentication failure. The following steps outline the screens displayed to the user and the actions required to proceed. When behavioral authentication fails during Windows login, fallback authentication is triggered. Follow the steps below to complete the sign-in process. #### Enter your username {% stepper %} {% step %} #### **On the Sign In – Enter your username screen, enter your username and press Enter.** {% endstep %} {% step %} #### Choose Behavior Auth On the **Sign In – Choose an authentication method** screen, click **Behavior Auth**. {% endstep %} {% step %} #### Enter the phrase Enter the phrase displayed on the screen and press Enter. {% endstep %} {% step %} #### Enter the PIN Enter the PIN and press Enter. {% endstep %} {% step %} #### Fallback is triggered Based on the number of attempts configured in the AdminX interface (**Trigger fallback after number of attempts** field), if a user enters an incorrect PIN and exceeds the specified attempt limit, a **Trouble Logging In?** screen is displayed. This screen prompts the user to contact the Helpdesk to obtain a passcode. {% endstep %} {% step %} #### Choose Helpdesk Code Click the **Helpdesk Code**. The following screen is displayed. At this stage, reach out to your helpdesk admin to receive the code. The following table outlines what happens when you click each link: | When you click... | The UI | | --------------------------- | --------------------------------------------------------------------------- | | Helpdesk code | Takes you to the new screen to enter the code provided by Helpdesk. | | Return to all login options | Displays all the configured adaptive authentication journeys for that user. | | {% endstep %} | | {% step %} #### Enter the bypass code Enter the bypass code received from your helpdesk admin. {% endstep %} {% step %} #### Login successful Upon successful validation of the passcode, the Login successful message is displayed to the user. {% endstep %} {% step %} #### Reset your MFA The user is prompted to reset one of their authentication methods. The **Reset your MFA** screen is displayed only to users who: * Have Behavioral Authentication and/or PIN authentication enabled in the configured authentication journey, and * Have previously enrolled in those authentication methods. {% endstep %} {% step %} #### Select the method to reset On the **Reset your MFA** screen, click the authentication method that needs to be reset. In this scenario, select **User PIN**. {% endstep %} {% step %} #### Complete the reset After selecting User PIN, the **Begin Setup** screen appears. The user must enter a new PIN and click Submit to complete the reset process. Upon successful setup, the user is logged into the workstation. {% endstep %} {% endstepper %} ### Step 3: Generating Passcodes Community Administrators or users with the **user.helpdesk-passcode.generate** permission can generate a passcode for users who contact the Helpdesk after behavioral authentication fails during workstation login. The passcode is a randomly generated six-digit number. The administrator can specify how long the passcode remains valid. To generate a passcode from the AdminX interface: {% stepper %} {% step %} #### Log in Log in to your tenant as a community administrator. {% endstep %} {% step %} #### Open All Users Navigate to **Users > All Users**. {% endstep %} {% step %} #### Generate Passcode Click **Generate Passcode**. {% endstep %} {% step %} #### Set the expiry In the **Generate One-Time Passcode** screen, specify the duration after which the passcode will expire. The duration can be specified in either minutes or hours. * Minimum duration: 1 minute * Maximum duration: 24 hours * Default duration: 10 minutes {% endstep %} {% step %} #### Generate Click **Generate**. {% endstep %} {% endstepper %} ### Event Logs The following events are triggered as part of the Fallback Authentication workflow: * **E\_FALLBACK\_AUTH\_CONFIGURED** – Triggered when fallback authentication settings are updated from the Windows MFA Settings page, such as enabling or disabling the feature or modifying the configured attempt threshold. * **E\_FALLBACK\_JOURNEY\_CREATED** – Triggered when a new fallback authentication journey is created. * **E\_FALLBACK\_JOURNEY\_MODIFIED** – Triggered when an existing fallback authentication journey is modified. * **E\_FALLBACK\_JOURNEY\_DELETED** – Triggered when a configured fallback authentication journey is deleted. * **E\_OTP\_REQUESTED** – Triggered when a request is made to generate a one-time passcode (OTP). * **E\_OTP\_GENERATED** – Triggered when the OTP is successfully generated. * **E\_OTP\_VERIFIED** – Triggered when the OTP verification process is completed, indicating whether the verification was successful or failed. # Run As & UAC 1Kosmos Credential Provider intercepts Run As and UAC elevation prompts, requiring MFA before elevated access is granted. From v2.0.7.0, passwordless authentication is supported for these scenarios. *** ### Admin Setup **Default Behaviour** No separate journey configuration is required for Run As or UAC interception. The Credential Provider automatically intercepts Windows CredUI flows (right-click "Run as different user" and UAC elevation prompts) and applies the MFA method defined in the user's existing Adaptive Auth Journey. **Disabling 1Kosmos for CredUI Only** To disable 1Kosmos interception for Run As / UAC prompts while keeping it active for login and unlock, set the following registry value: ```bash HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos\BlockIDCredentialProvider Value name: Disable1KosmosOnCredUI Value type: DWORD Value data: 1 ``` **Enabling Passwordless Run As and RDP (v2.0.7.0+)** For passwordless authentication to function in Run As and RDP scenarios, the `SmartCardCredentialProvider` must be enabled on the workstation. 1. Open the registry editor and navigate to the following key: ```bash HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{8FD7E19C-3BF7-489B-A72C-846AB3678C96} ``` 2. If the `Disabled` value exists and is set to `1`, change it to `0`. 3. If the `Disabled` value does not exist, no action is required — the provider is active by default. {% hint style="info" %} Both the source and destination machines must have the 1Kosmos Credential Provider installed for passwordless RDP to function end-to-end. {% endhint %} **Controlling Password Provider Visibility in CredUI** To independently control whether the standard Windows password provider is shown in CredUI prompts (Run As / UAC), set the following registry value: ```bash HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos\BlockIDCredentialProvider Value name: DisablePwdOnCredUI Value type: DWORD Value data: 1 ``` *** ### User Guide **Run As Different User** 1. Right-click the application you want to run with elevated or different credentials. 2. Select **Run as different user**. 3. In the Windows credential prompt, click **More options**. 4. Click **Login with 1Kosmos**. 5. Enter the username of the account to run the application as. 6. Select your MFA method from the available options. 7. Complete the MFA challenge (e.g., approve push, scan QR, provide fingerprint). 8. The application launches under the specified account's permissions. **UAC Elevation** 1. When a UAC prompt appears (e.g., when installing software or modifying system settings), click **More options**. 2. Click **Login with 1Kosmos**. 3. Complete the MFA challenge using your configured authentication method. 4. Elevation is granted and the operation proceeds. **Passwordless Run As / RDP (v2.0.7.0+)** When the user's Adaptive Auth Journey includes a passwordless method (QR Code, Push Notification, or FIDO), those methods are available during Run As and RDP authentication — no password entry is required. 1. Initiate Run As or open an RDP connection to a remote machine. 2. At the credential prompt, click **More options > Login with 1Kosmos**. 3. The passwordless methods configured in your journey are presented (e.g., QR Code, Push Notification, Security Key). 4. Complete the passwordless MFA challenge. 5. Access is granted. {% hint style="info" %} For RDP logins without the passwordless configuration, a password is enforced alongside any other MFA factor by default. For fully passwordless RDP, both the source machine (initiating the connection) and the destination machine (being connected to) must have the 1Kosmos Credential Provider installed and the SmartCardCredentialProvider must be enabled as described in [Admin Setup](#admin-setup). {% endhint %} *** ### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1Kosmos tile not appearing in Run As prompt | `SmartCardCredentialProvider` is disabled | Check the registry key at `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{8FD7E19C-3BF7-489B-A72C-846AB3678C96}` and ensure `Disabled` is not set to `1`; set it to `0` if present | | Passwordless methods not available in Run As | User's Adaptive Auth Journey does not include a passwordless method; SmartCardCredentialProvider disabled | Update the assigned journey to include QR, Push, or FIDO; verify SmartCardCredentialProvider is enabled | | UAC prompt not intercepted by 1Kosmos | `Disable1KosmosOnCredUI` registry key set to `1` | Set `Disable1KosmosOnCredUI` to `0` or remove the value. | | Passwordless RDP not functioning | Agent not installed on one or both machines; SmartCardCredentialProvider disabled on destination | Ensure both source and destination machines have the Credential Provider installed; verify SmartCardCredentialProvider status on the destination machine | | Application does not launch after MFA completion | Incorrect alternate account credentials; account permissions insufficient | Verify the username entered in the Run As dialog is correct and has the required permissions to run the application | # Deployment Scenarios 1Kosmos Credential Provider intercepts Run As and UAC elevation prompts, requiring MFA before elevated access is granted. From v2.0.7.0, passwordless authentication is supported for these scenarios. *** ### Overview The 1Kosmos Credential Provider is installed on workstations and servers. Once installed, it intercepts Windows authentication events, login, unlock, Run As, UAC, and RDP, and enforces MFA according to the Adaptive Auth Journey assigned to the user. The behaviour of the agent varies depending on the environment it is deployed in. The pages in this section document each supported deployment scenario, its prerequisites, and any configuration specific to that environment. ### Deployment Scenarios | Scenario | Description | | --------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | [Standard Domain-Joined Workstations](/authentication/windows-workstation-mfa/deployment-scenarios/standard-domain-joined-workstations) | The baseline deployment - Active Directory domain-joined machines with full network connectivity to the 1Kosmos tenant | | [RDP / Remote Desktop](/authentication/windows-workstation-mfa/deployment-scenarios/rdp) | Incoming and outgoing RDP sessions, covering both configurations where the agent is installed on the remote server and where it is not | | [Shared Workstations / CyberArk PAM](/authentication/windows-workstation-mfa/deployment-scenarios/shared-workstations) | Shared device environments using CyberArk Privileged Access Management for shared account authentication via 1Key | | [Offline / Disconnected Environments](/authentication/windows-workstation-mfa/deployment-scenarios/offline-scenario) | Workstations that operate without network connectivity, using cached credentials for authentication | | Local Accounts / Break-Glass | Configuration for local (non-domain) accounts and emergency break-glass access when MFA cannot be completed | | [Entra ID Joined Machines](/authentication/windows-workstation-mfa/deployment-scenarios/entra-joined-workstations) | Support for Microsoft Entra ID joined machines - currently on the product roadmap | *** ### General Prerequisites The following prerequisites apply across all deployment scenarios unless explicitly noted otherwise on a scenario-specific page. | Prerequisite | Requirement | | ---------------------- | ----------------------------------------------------------------------------------------- | | Operating system | Windows 10 (1903+), Windows 11, Windows Server 2016, 2019, 2022 | | Agent version | See individual scenario pages for version-specific requirements | | Installation directory | `C:\Program Files\1Kosmos\BlockIDCredentialProvider` | | Log directory | `C:\Program Files\1Kosmos\BlockIDCredentialProvider\Logs` | | Network connectivity | Required for all online authentication methods | | AdminX access | Administrator access to the 1Kosmos AdminX portal for journey configuration | | Active Directory | Required for domain-joined scenarios; local account scenarios operate independently of AD | {% hint style="info" %} Installation and system prerequisites are covered in detail in [Installation.](/authentication/windows-workstation-mfa/installation) This section assumes the agent is already installed and the base configuration is complete. {% endhint %} # Standard Domain Joined Workstations Baseline deployment scenario for 1Kosmos Windows Workstation MFA Agent. Covers Active Directory domain-joined machines with full network connectivity to 1Kosmos tenant. *** ### Overview Standard domain-joined workstations represent the most common deployment of the 1Kosmos Credential Provider. In this scenario: * The workstation is joined to an Active Directory domain. * The Credential Provider is installed on the workstation. * The workstation has network connectivity to the 1Kosmos tenant at all times during authentication. * Users authenticate using their AD credentials combined with an MFA method defined in an Adaptive Auth Journey. All authentication methods documented in the [Authentication Methods ](/authentication/windows-workstation-mfa/authentication-methods)section are supported in this scenario. ### Admin Setup #### Prerequisites | Requirement | Detail | | --------------------------- | --------------------------------------------------------------------------- | | Domain membership | Machine must be joined to an Active Directory domain | | Agent installed | Credential Provider installed on each target workstation | | User accounts | Users must have accounts in Active Directory | | 1Kosmos tenant connectivity | Workstation must be able to reach the 1Kosmos tenant over HTTPS (port 443) | | User enrollment | Users must be enrolled in the 1Kosmos platform with at least one MFA method | #### Configure the Authentication Journey 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Create a new journey or edit an existing one. 3. Select the desired authentication method (see [Authentication Methods ](/authentication/windows-workstation-mfa/authentication-methods)for all available options). 4. Under **Assignment**, assign the journey to the target user group, organisational unit, or machine policy as appropriate for your environment. 5. Save and publish the journey. #### Group Policy Deployment (Recommended) For environments with multiple workstations, deploy the Credential Provider via Group Policy Object (GPO) to ensure consistent installation and configuration across all target machines. 1. Place the installer package in a network share accessible to all target machines. 2. Create a new GPO and link it to the target OU. 3. Under **Computer Configuration > Software Settings > Software Installation**, add the MSI package. 4. Configure the `REGCONFIG.ini` settings file with your tenant URL, tenant ID, and policy settings before deployment. 5. Apply the GPO and verify installation on a test machine before broad rollout. {% hint style="info" %} See [Installation](/authentication/windows-workstation-mfa/installation/install-using-msi) for full MSI deployment parameters and `REGCONFIG.ini` configuration reference. {% endhint %} #### Verify Connectivity After installation, confirm the workstation can reach the 1Kosmos tenant before expecting users to authenticate. 1. On the workstation, open a browser and navigate to your 1Kosmos tenant URL. 2. Confirm the page loads without SSL or connection errors. 3. Review the Credential Provider logs at `C:\Program Files\1Kosmos\BlockIDCredentialProvider\Logs` for any connectivity errors on the first login attempt. #### User Guide #### Login 1. At the Windows login screen, click the **1Kosmos** tile. 2. If using the **Other User** tile, enter your domain username (in `DOMAIN\username` or `username@domain` format) first. 3. Complete the authentication steps required by your assigned journey. 4. The Windows session unlocks and you are logged in. #### Unlock The same authentication flow applies when unlocking a locked workstation. Press any key or move the mouse to wake the screen, then click the **1Kosmos** tile and complete your assigned MFA method. {% hint style="info" %} If a user's journey requires push notification or QR code, the mobile device must be available at the time of unlock. For environments where users frequently step away from their desks without their phones, consider enabling [Offline / Disconnected Environments ](/authentication/windows-workstation-mfa/deployment-scenarios/offline-scenario)support with cached PIN as a fallback. {% endhint %} #### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1Kosmos tile not visible on login screen | Agent not installed correctly; Credential Provider service not running | Verify installation in `C:\Program Files\1Kosmos\BlockIDCredentialProvider`; check Windows Services for the 1Kosmos service; re-run the installer if necessary | | Authentication fails with "User not found" | User's AD account not synced to the 1Kosmos tenant; UPN mismatch | Verify the user exists in AdminX under **Users > All Users**; confirm the UPN format matches between AD and the 1Kosmos tenant | | Authentication fails consistently for all users | Tenant connectivity lost; certificate issue | Check network connectivity from the workstation to the tenant URL; review logs at `C:\Program Files\1Kosmos\BlockIDCredentialProvider\Logs` for error details | | User not prompted for MFA — logs in with password only | No journey assigned to the user or machine | Verify the user is included in the assignment scope of a published Adaptive Auth Journey in AdminX | | Login screen reverts to standard Windows provider | Credential Provider service crashed | Restart the 1Kosmos Credential Provider service; review logs for crash details; contact 1Kosmos support if recurring | # RDP 1Kosmos Credential Provider supports MFA enforcement for both incoming and outgoing Remote Desktop Protocol (RDP) sessions. *** ### RDP with Agent on the Remote Server When the 1Kosmos Credential Provider is installed on both the source machine and the destination server, fully passwordless RDP is supported from v2.0.7.0. The destination server enforces MFA using the user's assigned Adaptive Auth Journey, and passwordless methods (QR Code, Push Notification, FIDO) are available without requiring a password. ### Admin Setup **Prerequisites** | Requirement | Detail | | --------------------------- | ---------------------------------------------------------------------------------------------- | | Agent version | v2.0.7.0 or later on both source and destination machines | | Agent installed | Credential Provider installed on the destination server as well as the source workstation | | SmartCardCredentialProvider | Must be enabled on the destination server (see below) | | Journey configured | User's Adaptive Auth Journey must include at least one passwordless method (QR, Push, or FIDO) | **Enable SmartCardCredentialProvider on the Destination Server** 1. On the destination server, open the registry editor and navigate to: ``` HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{8FD7E19C-3BF7-489B-A72C-846AB3678C96} ``` 2. If the `Disabled` value exists and is set to `1`, change it to `0`. 3. If the `Disabled` value does not exist, no action is required, the provider is active by default. 4. Restart the server or the Credential Provider service for the change to take effect. {% hint style="info" %} This registry key must be configured on the **destination** server, not the source workstation. If it is disabled on the destination, the 1Kosmos tile will not appear in the RDP credential prompt. {% endhint %} **Configure the Authentication Journey** 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Ensure the journey assigned to the user includes a passwordless authentication method. 3. Confirm the journey is assigned to the user group that will be connecting via RDP. 4. Save and publish the journey. ### User Guide **Passwordless RDP Login** 1. On the source machine, open **Remote Desktop Connection** and enter the hostname or IP address of the destination server. 2. Click **Connect**. 3. At the RDP credential prompt, click **More options**. 4. Click **Login with 1Kosmos**. 5. The passwordless methods configured in your journey are presented (e.g., QR Code, Push Notification, Security Key). 6. Complete the MFA challenge. 7. The RDP session is established and you are logged in to the remote server. {% hint style="info" %} If both a password and a passwordless method are configured in the journey, both will be presented. For a fully passwordless experience, ensure the journey is configured with a passwordless-only method. {% endhint %} ### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1Kosmos tile not appearing in RDP credential prompt | SmartCardCredentialProvider disabled on destination; agent not installed on destination | Verify the registry key on the destination server; confirm the Credential Provider is installed on the destination | | Passwordless methods not available | Journey does not include a passwordless method | Update the assigned journey to include QR, Push, or FIDO | | RDP session fails after MFA completion | Network issue between source and destination; RDP port blocked | Verify RDP connectivity (port 3389) between source and destination; check Windows Firewall rules on the destination server | | User prompted for password despite passwordless journey | NLA (Network Level Authentication) enforcing credentials before the 1Kosmos tile appears | Disable NLA on the destination server if fully passwordless RDP is required; note that disabling NLA has security implications, consult your security policy | ### RDP without Agent on the Remote Server When the destination server does not have the 1Kosmos Credential Provider installed, the destination enforces standard Windows NLA/password authentication for the RDP session. In this configuration, 1Kosmos MFA cannot be enforced at the point of RDP session establishment on the destination. The source workstation may still enforce MFA for local login and unlock events, but the RDP connection itself is governed by the destination's native Windows authentication. {% hint style="warning" %} This configuration does not provide end-to-end MFA enforcement for RDP sessions. Users authenticate with a password at the RDP prompt on the destination server. This is a common scenario during phased rollouts where the agent has not yet been deployed to all servers. Plan agent deployment on destination servers to close this gap. {% endhint %} ### Admin Setup No additional configuration is required in AdminX for this scenario. The destination server uses standard Windows authentication. If your organisation requires MFA enforcement for all RDP sessions including to servers without the agent, consider one of the following approaches: | Approach | Description | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Deploy agent to destination servers | Install the Credential Provider on the destination server to enable full MFA enforcement | | RDP Gateway with MFA | Route RDP sessions through an RD Gateway that enforces MFA at the gateway level before the session reaches the destination | | Network access control | Restrict RDP access to destination servers via firewall rules so that only source machines with the agent installed can initiate connections | {% hint style="info" %} See [Configuration Reference](#) for the `Disable1KosmosOnCredUI` registry key if you need to control whether 1Kosmos intercepts CredUI prompts on the source machine during RDP initiation. {% endhint %} ### User Guide **RDP Login (No Agent on Destination)** 1. On the source machine, open **Remote Desktop Connection** and enter the hostname or IP address of the destination server. 2. Click **Connect**. 3. At the RDP credential prompt, enter your Windows username and password. 4. The RDP session is established using standard Windows authentication. {% hint style="info" %} No 1Kosmos MFA step occurs at the destination in this configuration. MFA is only enforced on the source workstation for local login and unlock events. {% endhint %} ### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | User expects 1Kosmos tile but sees only password prompt | Agent not installed on destination server | Install the Credential Provider on the destination server. | | RDP connection refused | Destination server not configured to accept RDP; firewall blocking port 3389 | Enable Remote Desktop on the destination server; verify firewall rules permit RDP traffic from the source | | Credential prompt loops without connecting | Incorrect username or password; account locked on destination | Verify credentials; check account status in Active Directory | # Shared Workstations Shared workstation environments allow multiple users to authenticate on the same physical machine using their individual identities, then access shared or privileged accounts managed by CyberArk. *** ### Overview In a shared workstation deployment, no individual user has a dedicated Windows session. Instead: 1. A user approaches the workstation and authenticates their **personal identity** using a 1Kosmos MFA method (typically 1Key biometric authentication). 2. The Credential Provider queries CyberArk PAM for the list of shared accounts that user is authorised to access. 3. The user selects the appropriate shared account from the list. 4. Windows opens a session under the selected shared account. This model is common in manufacturing, healthcare, retail, and contact centre environments where employees share terminals but individual accountability must be maintained. {% hint style="info" %} **Note:** The authentication steps for shared account login are documented in [FIDO / 1Key, Shared Account Login with 1Key.](/authentication/1key-biometric/deployment-guide) This page covers the deployment prerequisites, CyberArk integration setup, and environment-specific configuration. {% endhint %} *** ### Admin Setup #### Prerequisites | Requirement | Detail | | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | | CyberArk PAM | CyberArk Privileged Access Management deployed and configured in your environment | | 1Key hardware key | Each user must have a 1Key enrolled; see [1Key Enrollment Documentation](/authentication/1key-biometric/deployment-guide) | | Agent version | Credential Provider installed on all shared workstations | | CyberArk integration | 1Kosmos–CyberArk integration configured in AdminX (see below) | | User entitlements | Each user's CyberArk entitlements must be configured to reflect the shared accounts they are authorised to access | #### Configure the CyberArk Integration in AdminX 1. In AdminX, navigate to **Integrations > CyberArk PAM**. 2. Enter your CyberArk server URL, application ID, and API credentials. 3. Test the connection to verify AdminX can communicate with CyberArk. 4. Save the integration settings. #### Configure the Authentication Journey 1. In AdminX, navigate to **Applications > Windows MFA > Adaptive Auth Journeys**. 2. Create a new journey or edit an existing one. 3. Under **Authentication Method**, select **FIDO for Shared Account Login**. 4. Assign the journey to the user group or machine policy covering all shared workstation users. 5. Save and publish the journey. {% hint style="info" %} **Note:** The FIDO for Shared Account Login journey type triggers the CyberArk account lookup after successful biometric authentication. Journeys configured with the standard FIDO method will not present the shared account selection screen. {% endhint %} ### Workstation Configuration Shared workstations typically auto-lock after a short idle period to ensure the session is always in a locked state when a new user approaches. 1. Configure the Windows screen lock timeout via Group Policy: **Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon: Machine inactivity limit**. 2. Set the inactivity limit to a value appropriate for your environment (e.g., 60–120 seconds). 3. Optionally, configure the workstation to display a custom lock screen message (e.g., "Place your 1Key to log in") via Group Policy: **Computer Configuration > Administrative Templates > Control Panel > Personalization > Force a specific lock screen image**. *** #### User Guide See [FIDO / 1Key, Shared Account Login with 1Key ](/authentication/1key-biometric/user-guide)for the step-by-step login flow. *** #### Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Shared account list does not appear after biometric authentication | Journey configured with standard FIDO instead of FIDO for Shared Account Login; CyberArk integration not configured | Verify the journey uses the FIDO for Shared Account Login method; verify the CyberArk integration is configured and connected in AdminX | | Expected shared account not visible in the list | User's CyberArk entitlement not granted for that account | Verify the user's CyberArk account permissions with your PAM administrator | | 1Key not recognised at the workstation | Key not enrolled; USB connection issue; Credential Provider not running | Try a different USB port; verify key enrollment; confirm the Credential Provider service is running | | CyberArk connection error in AdminX | API credentials expired or incorrect; network connectivity between 1Kosmos and CyberArk lost | Re-enter and test CyberArk API credentials in AdminX **Integrations > CyberArk PAM**; verify network connectivity | | Session not locking between users | Inactivity timeout not configured; GPO not applied to workstation | Verify the GPO inactivity policy is applied and effective on the workstation using `gpresult /h report.html` | # Offline Scenario Securely log into your Windows workstation even without internet access or when the 1Kosmos cloud is unreachable, using offline authentication methods supported by the 1Kosmos Credential Provider. *** ### Overview There are situations where network access isn't always guaranteed - whether you're traveling, working in a low-connectivity area, or on a flight. The 1Kosmos Windows Workstation MFA agent ensures you can still securely access your workstation even when there is no internet connection or the 1Kosmos cloud is temporarily unavailable. When the Credential Provider detects an offline state, it automatically switches to supported offline authentication methods. Online methods such as Push Notification, QR Code, SMS/Email/Voice OTP, and online FIDO are not available without connectivity. The following offline methods are supported: * PIN * OTP For the best offline authentication experience, it is recommended to complete at least one passwordless online login beforehand. However, this is not mandatory, if passwordless login was never configured, the offline login will prompt the user to enter their password and OTP. The Windows Workstation MFA agent supports offline login for both domain and local users. To enable offline logins, the community seed must be configured in the registry of the target workstation. When the system is offline, the Windows Workstation MFA agent shows an offline indicator on the UI. If the community seed is unavailable, the agent notifies users that offline login is not enabled when they attempt to log in. However, 1Kosmos still allows users to log in with local accounts in such cases. By adopting this feature, users can enjoy seamless access during offline scenarios using the Account OTP from the 1Kosmos mobile app. If passwordless login has not been completed beforehand, the password will serve as an additional factor for offline authentication. Starting with Release v2.0.8.0, multi-factor authentication (MFA) methods are displayed for both local and remote account logins. To enable MFA for a local user, the local account must be added as an alias. Administrators can configure the authentication journey for primary users via the AdminX interface. While in AdminX interface, they must add local user as an alias for primary user. If no custom journey is set for the primary user, the Windows Workstation MFA Agent will display the default five options: password, OTP, QR, FIDO and Push. Users can select any of these methods to log in to the workstation. The local users still need to enter their password. **Offline Login Behavior (Local Users):** * If Offline Login is enabled (i.e., the community seed is configured): * The local user associated with an alias is prompted to enter the Account OTP of the primary user along with their password to log in. * If Offline Login is not enabled (i.e., the community seed is not configured): * The local user can log in using only their password, without needing to provide the Account OTP. #### Enabling Offline Login Mechanism To enable offline login support, the administrator must add the OTP Seed to the system registry of the Windows Workstation MFA agent. To associate the OTP Seed with the registry, follow these steps: 1. Navigate to the Adminx interface. 2. Go to **Authentication > Multi-Factor Authentication > Account OTP for Offline Authentication** section and copy the OTP seed. 3. Navigate to the following registry path: ``` HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{90576E81-DDF8-4E8E-91E2-CA3A9CE52410} ``` 4. Create a registry key in the following format: ``` CommunitySeed_$dns_$communityName ``` 5. In dns and communityName, replace any occurrence of “.” with “\_” so that the updated Registry Key name appears as follows: 6. Add the following registry keys. | Registry Key | Registry Type | | -------------------------------------------------- | ------------- | | CommunitySeed\_acme\_1Kosmos\_net\_default | REG\_SZ | | CommunitySeed\_acme-dev\_1Kosmos\_net\_development | REG\_SZ | The registry can be updated either through the SCCM / GPO update by the organization or via the BlockIDInstaller.bat script using the `-configure` directive. Administrators must update the `REGCONFIG` file to add the CommunitySeed and value. #### Sign in using Offline Login To access your workstation during offline, follow these steps: 1. In the login screen, click the **Other User** tile and select the **BlockID** option. 2. When the Sign In page displays the No Internet icon, enter your username and click Submit. 3. The available offline authentication methods are displayed based on your configuration: * OTP is available if Community Seed is configured. * PIN is available if Behavioral Authentication and PIN are configured, the user has completed PIN enrollment, and has successfully authenticated online at least once so that the PIN is cached. * If both configurations are available, both OTP and PIN options will be displayed. 4\. Select the desired authentication method: * Enter the Account OTP generated by the 1Kosmos mobile app, or * Enter your offline PIN. 5\. Upon successful authentication, you will be logged in to the workstation. **Note:** The cached offline PIN is invalidated after three consecutive incorrect attempts. Once the retry limit is reached, the user must authenticate online again to re-establish the cache ### Troubleshooting | Issue | Likely Cause | Resolution | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | PIN option not shown when offline | Behavior Auth & PIN not configured; user never completed online enrollment or has not authenticated online once. | Verify the journey uses Behavior Auth & PIN; reconnect to the network and complete enrollment before the next offline session | | Cached PIN cleared unexpectedly | 3 failed PIN attempts were made in a previous offline session | Reconnect the device to the network; complete an online login to re-establish the cached PIN | *** # Entra Joined Workstations Support for Microsoft Entra ID joined machines (formerly Azure AD joined) is on 1Kosmos product roadmap. This page will be updated when the feature is available. *** ### What to Expect Entra ID joined machines are Windows devices that are joined directly to Microsoft Entra ID rather than to an on-premises Active Directory domain. This model is increasingly common in cloud-first and hybrid organisations where traditional domain infrastructure is being reduced or eliminated. {% hint style="warning" %} **Beta** This feature is currently in Beta and available for testing. The information below reflects planned scope and is subject to change. No configuration steps or user guidance are provided on this page until the feature reaches general availability. {% endhint %} ### In the Meantime For organisations that require MFA on Windows devices managed through Entra ID today, the following interim options may be applicable: | Option | Description | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Hybrid Entra ID Join | Join machines to both on-premises AD and Entra ID; deploy the 1Kosmos Credential Provider using the standard domain-joined model | | Microsoft Entra ID external authentication | 1Kosmos integrates with Microsoft Entra ID as an external authentication provider for app and web access; see [1Kosmos + Microsoft Entra ID Integration](https://www.1kosmos.com/platform/resources/integrations/microsoft-entra-verified-id?utm_campaign=46345118-Developer%20Center\&utm_source=docsite\&utm_medium=website\&utm_content=entra-id-link) for details | # Uninstall 1Kosmos Windows Workstation MFA Agent can be uninstalled using either the MSI or EXE method, depending on how it was originally installed. A reboot is required after uninstall to remove the machine. *** #### Choosing the Right Uninstall Method Use the method that matches how the agent was installed on the target machine. | If the agent was installed using | Use | | ------------------------------------------------- | ------------- | | The MSI package (`1KosmosCredentialProvider.msi`) | Uninstall MSI | | The EXE installer (`1KosmosInstaller.exe`) | Uninstall EXE | {% hint style="info" %} **Note:** If you are unsure which installer was used, check **Settings > Apps** or **Control Panel > Programs and Features** for the entry name. Both methods produce the same uninstall result — the difference is only in the removal mechanism. {% endhint %} *** #### What Uninstall Removes | Item | Removed on Uninstall | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Credential Provider binaries | Yes | | Installation directory (`C:\Program Files\1Kosmos\BlockIDCredentialProvider`) | Yes | | Registry entries for the Credential Provider | Yes | | Log files (`C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs`) | Yes — directory is removed with the installation folder | | Configuration applied via `REGCONFIG.ini` at install time | Yes — registry values written during install are removed | | User enrollment data | No — enrollment data is stored in the 1Kosmos tenant, not on the workstation | | AdminX journey configuration | No — journey and policy configuration in AdminX is unaffected | {% hint style="info" %} **Note:** Because enrollment and journey configuration are tenant-side, uninstalling the agent from a workstation does not affect other workstations or the user's enrolled MFA methods. Re-installing the agent on the same machine will restore MFA enforcement without requiring re-enrollment. {% endhint %} *** #### Before You Uninstall * Confirm you have **Local Administrator or Domain Administrator** rights on the target machine. * Ensure no users are actively logged in to the workstation. * Plan for a **reboot immediately after uninstall** — the 1Kosmos tile will remain visible on the login screen until the machine is restarted. * If uninstalling as part of a rollback or incident response, notify affected users that standard Windows authentication will be active after reboot. {% hint style="warning" %} **Warning:** Uninstalling the Credential Provider removes all 1Kosmos MFA enforcement from the workstation. Users will revert to standard Windows password authentication immediately after reboot. Ensure this is intentional and that any compliance or access control requirements are addressed before proceeding. {% endhint %} # Uninstall MSI Uninstalling 1Kosmos Windows Workstation MFA Agent via MSI package. Supports both silent (command-line) and UI-guided removal. *** ### Prerequisites | Requirement | Detail | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Privileges | Local Administrator or Domain Administrator rights on the target machine | | MSI product code | Required for silent uninstall via `msiexec`; see [Locate the Product Code](#locate-the-product-code) below | | Active sessions | Ensure no users are actively logged in to the workstation before uninstalling | | Reboot window | Plan for a reboot immediately after uninstall, the 1Kosmos tile will remain on the login screen until the machine is restarted | {% hint style="warning" %} Uninstalling the Credential Provider removes all 1Kosmos MFA enforcement from the workstation. Users will revert to standard Windows authentication immediately after reboot. Ensure this is intentional and that any compliance or access control requirements are addressed before proceeding. {% endhint %} ### Locate the Product Code The MSI product code is required for silent uninstall. It is unique to each version of the installer. **Option 1 — Windows Registry:** 1. Open the registry editor and navigate to: ```bash HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall ``` 2. Search for a subkey with `DisplayName` matching **1Kosmos BlockID Credential Provider** (or **BlockID Credential Provider** on versions prior to v2.4.0.0). 3. Note the `ProductCode` value — it will be in the format `{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}`. **Option 2 — PowerShell:** ```bash Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*BlockID*" -or $_.Name -like "*1Kosmos*" } | Select-Object Name, IdentifyingNumber ``` The `IdentifyingNumber` field is the product code. {% hint style="info" %} The product code changes with each installer version. Always retrieve the code from the target machine rather than reusing a code from a previous installation. {% endhint %} ### Silent Uninstall Silent uninstall is the recommended method for managed environments and GPO-based deployments. It runs without any user interaction and suppresses the reboot prompt - schedule the reboot separately. ### Basic Silent Uninstall Run the following command from an elevated command prompt or deployment tool: ```bash msiexec /x {PRODUCT-CODE-HERE} /qn /norestart ``` | Flag | Description | | --------------------- | ---------------------------------------------------- | | `/x` | Uninstall mode | | `{PRODUCT-CODE-HERE}` | Replace with the actual product code retrieved above | | `/qn` | No UI - fully silent | | `/norestart` | Suppresses automatic reboot; schedule separately | ### Silent Uninstall with Log Output To capture uninstall activity for troubleshooting or audit purposes: ```bash msiexec /x {PRODUCT-CODE-HERE} /qn /norestart /l*v "C:\Logs\1kosmos_uninstall.log" ``` | Flag | Description | | --------------------------------- | ------------------------------------------------------------------------ | | `/l*v` | Verbose logging | | `"C:\Logs\1kosmos_uninstall.log"` | Path to the output log file - ensure the directory exists before running | ### Reboot After Silent Uninstall After the uninstall command completes, restart the workstation: ```bash shutdown /r /t 0 ``` Or, if scheduling via a deployment tool, trigger a managed reboot at an appropriate time within your maintenance window. {% hint style="warning" %} Do not leave the workstation in a post-uninstall, pre-reboot state for longer than necessary. The 1Kosmos tile will still appear on the login screen in this state, and attempting to authenticate through it may produce errors. {% endhint %} ### UI Uninstall #### Via Windows Settings 1. Open **Settings > Apps > Installed Apps** (Windows 11) or **Settings > Apps & Features** (Windows 10). 2. Search for **1Kosmos BlockID Credential Provider** (or **BlockID Credential Provider** on versions prior to v2.4.0.0). 3. Click the entry and select **Uninstall**. 4. Confirm the uninstall prompt. 5. The uninstall wizard runs and completes. 6. When prompted, click **Restart Now** to reboot the workstation, or restart manually at the next available opportunity. #### Via Control Panel 1. Open **Control Panel > Programs > Programs and Features**. 2. Locate **1Kosmos BlockID Credential Provider** in the list. 3. Right-click the entry and select **Uninstall**. 4. Follow the uninstall wizard to completion. 5. Reboot the workstation when prompted. {% hint style="info" %} After reboot, verify the 1Kosmos tile no longer appears on the Windows login screen. If it persists, see [Troubleshooting](#troubleshooting). {% endhint %} #### Post-Uninstall Verification After rebooting, confirm the uninstall is complete: 1. At the Windows login screen, verify the **1Kosmos** tile is no longer present. 2. Confirm standard Windows authentication (password or PIN) is available. 3. Verify the installation directory has been removed: ```bash Test-Path "C:\Program Files\1Kosmos\BlockIDCredentialProvider" ``` This command should return `False`. If it returns `True`, residual files remain - see [Troubleshooting](#troubleshooting). 4. Optionally, review the uninstall log (if generated) at the path specified during silent uninstall. ### Troubleshooting | Issue | Likely Cause | Resolution | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `msiexec /x` returns error 1605 | Product code not found, the package is not installed, or the code is incorrect | Verify the product code using the PowerShell command above; confirm the agent is installed on the target machine | | `msiexec /x` returns error 1603 | Uninstall failed, insufficient privileges or a file is locked | Run the command from an elevated prompt; close any applications that may have files open in the installation directory | | 1Kosmos tile still visible after reboot | Residual registry entries or files not removed during uninstall | Check for leftover files in `C:\Program Files\1Kosmos\BlockIDCredentialProvider`; check for residual registry entries under `HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos`; contact 1Kosmos support for a cleanup script if necessary | | Uninstall entry not visible in Apps / Control Panel | Agent was installed via a different mechanism or the installer record is corrupted | Use the `msiexec /x` silent method with the product code retrieved from the registry or PowerShell | | Windows login screen shows no credential providers after reboot | Credential provider registration not restored correctly | Reboot the workstation a second time; if the issue persists, run a Windows repair using `sfc /scannow` from an elevated prompt | # Uninstall EXE Uninstalling 1Kosmos Windows Workstation MFA Agent when it was installed using EXE installer package. Supports both silent (command-line) and UI-guided removal. *** ### Prerequisites | Requirement | Detail | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Privileges | Local Administrator or Domain Administrator rights on the target machine | | Original installer or uninstaller | The EXE-based uninstall can be triggered via the original installer (run in uninstall mode), via Windows Apps / Control Panel, or via the uninstaller registered at `C:\Program Files\1Kosmos\1KosmosCredentialProvider\uninstall.exe` | | Active sessions | Ensure no users are actively logged in to the workstation before uninstalling | | Reboot window | Plan for a reboot immediately after uninstall, the 1Kosmos tile will remain on the login screen until the machine is restarted | {% hint style="warning" %} Uninstalling the Credential Provider removes all 1Kosmos MFA enforcement from the workstation. Users will revert to standard Windows authentication immediately after reboot. Ensure this is intentional and that any compliance or access control requirements are addressed before proceeding. {% endhint %} *** ### Silent Uninstall Silent uninstall is the recommended method for managed environments. It runs without user interaction and suppresses the reboot prompt, schedule the reboot separately. #### Using the Registered Uninstaller The EXE installer registers a dedicated uninstaller in the installation directory. Run the following from an elevated command prompt or deployment tool: ```bash "C:\Program Files\1Kosmos\1KosmosCredentialProvider\uninstall.exe" /S ``` | Flag | Description | | ---- | -------------------------------- | | `/S` | Silent mode , no UI, no prompts | {% hint style="info" %} The `/S` flag is case-sensitive. Using `/s` (lowercase) may not produce silent behaviour on all installer versions. {% endhint %} #### Using the Original EXE Installer in Uninstall Mode If the registered uninstaller is not available, the original EXE installer can be run in uninstall mode: ```bash "C:\Path\To\1KosmosInstaller.exe" /S /uninstall ``` Replace `C:\Path\To\1KosmosInstaller.exe` with the full path to the installer file. The installer version must match the installed version - using a different version may produce unpredictable results. #### Silent Uninstall with Log Output To capture uninstall activity for troubleshooting or audit purposes, redirect output to a log file: ```bash "C:\Program Files\1Kosmos\1KosmosCredentialProvider\uninstall.exe" /S > "C:\Logs\1kosmos_uninstall.log" 2>&1 ``` {% hint style="info" %} Ensure the log directory exists before running the command. {% endhint %} #### Reboot After Silent Uninstall After the uninstall command completes, restart the workstation: ```bash shutdown /r /t 0 ``` Or trigger a managed reboot via your deployment tool at an appropriate time within your maintenance window. {% hint style="warning" %} Do not leave the workstation in a post-uninstall, pre-reboot state for longer than necessary. The 1Kosmos tile will still appear on the login screen in this state, and attempting to authenticate through it may produce errors. {% endhint %} *** ### UI Uninstall {% stepper %} {% step %} #### Via Windows Settings 1. Open **Settings > Apps > Installed Apps** (Windows 11) or **Settings > Apps & Features** (Windows 10). 2. Search for **1Kosmos Credential Provider** (or **BlockID Credential Provider** on versions prior to v2.4.0.0). 3. Click the entry and select **Uninstall**. 4. Confirm the uninstall prompt. 5. The uninstall wizard runs and completes. 6. When prompted, click **Restart Now** to reboot the workstation, or restart manually at the next available opportunity. {% endstep %} {% step %} #### Via Control Panel 1. Open **Control Panel > Programs > Programs and Features**. 2. Locate **1Kosmos Credential Provider** in the list. 3. Right-click the entry and select **Uninstall**. 4. Follow the uninstall wizard to completion. 5. Reboot the workstation when prompted. {% endstep %} {% endstepper %} {% hint style="info" %} After reboot, verify the 1Kosmos tile no longer appears on the Windows login screen. If it persists, see [Troubleshooting](#troubleshooting). {% endhint %} *** ### Post-Uninstall Verification After rebooting, confirm the uninstall is complete: 1. At the Windows login screen, verify the **1Kosmos** tile is no longer present. 2. Confirm standard Windows authentication (password or PIN) is available. 3. Verify the installation directory has been removed: ```bash Test-Path "C:\Program Files\1Kosmos\1KosmosCredentialProvider" ``` This command should return `False`. If it returns `True`, residual files remain — see [Troubleshooting](#troubleshooting). *** ### Troubleshooting | Issue | Likely Cause | Resolution | | -------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `uninstall.exe /S` produces no output and no action | Incorrect path; uninstaller not present | Verify the file exists at `C:\Program Files\1Kosmos\1KosmosCredentialProvider\uninstall.exe`; if absent, use the Windows Settings or Control Panel method instead | | Uninstall appears to complete but 1Kosmos tile persists after reboot | Residual registry entries or files not removed | Check for leftover files in `C:\Program Files\1Kosmos\1KosmosCredentialProvider`; check for residual entries under `HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos`; contact 1Kosmos support for a cleanup script if necessary | | Uninstall entry not visible in Apps / Control Panel | Agent installer record corrupted or the entry was removed manually | Use the silent uninstall method via `uninstall.exe /S` or the original installer in uninstall mode | | Version mismatch warning when using original EXE in uninstall mode | Installer version does not match the installed agent version | Use the registered uninstaller at the installation directory instead; retrieve the correct installer version from your software distribution system if the registered uninstaller is unavailable | | Windows login screen shows no credential providers after reboot | Credential provider registration not restored correctly | Reboot the workstation a second time; if the issue persists, run `sfc /scannow` from an elevated command prompt | # Troubleshooting & Support This page covers cross-cutting issues with 1Kosmos Windows Workstation MFA Agent, installation failures, Credential Provider service problems, log collection, and connectivity diagnostics. *** ### Log Collection Logs are the first resource for any diagnosis. Collect them before escalating or attempting fixes. #### Log Location ```bash C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs ``` Logs are written per session and rotated automatically. The most recent log file reflects the last authentication event or service activity. #### Collecting Logs via PowerShell To copy the full log directory to a staging location for review or submission: ```bash Copy-Item -Path "C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs" -Destination "C:\Temp\1KosmosLogs" -Recurse ``` #### Enabling Verbose Logging By default, the Credential Provider writes standard-level logs. To enable verbose logging for a specific diagnostic session: 1. Open the registry editor and navigate to: ```bash HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos\1KosmosCredentialProvider ``` 2. Set the `LogLevel` value to `verbose`. 3. Reproduce the issue. 4. Collect the logs from the log directory. 5. Reset `LogLevel` to its previous value after collection. {% hint style="info" %} **Note:** Verbose logging increases log volume significantly. Disable it after the diagnostic session to avoid unnecessary disk usage. {% endhint %} *** ### Credential Provider Service Most login screen and authentication issues trace back to the Credential Provider service not running correctly. #### Check Service Status ```bash Get-Service -Name "1KosmosCredentialProvider" ``` The service status should be `Running`. If it is `Stopped` or `StartPending`, proceed with the steps below. #### Restart the Service ```bash Restart-Service -Name "1KosmosCredentialProvider" -Force ``` #### Start the Service if Stopped ```bash Start-Service -Name "1KosmosCredentialProvider" ``` #### Check Service Startup Type The service should be set to start automatically: ```bash Set-Service -Name "1KosmosCredentialProvider" -StartupType Automatic ``` {% hint style="info" %} **Note:** If the service fails to start repeatedly, review the Windows Event Viewer under **Windows Logs > Application** for error entries from `1KosmosCredentialProvider`. Also check the log directory at `C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs` for startup errors. {% endhint %} *** ### Connectivity Diagnostics Authentication methods that require network access (Push Notification, QR Code, SMS / Email / Voice OTP, online FIDO) will fail silently if the workstation cannot reach the 1Kosmos tenant. #### Test Tenant Connectivity ```bash Test-NetConnection -ComputerName -Port 443 ``` Replace `` with your organisation's 1Kosmos tenant hostname (e.g., `tenant.1kosmos.net`). A successful result shows `TcpTestSucceeded : True`. #### Test DNS Resolution ```bash Resolve-DnsName ``` If DNS resolution fails, the workstation cannot locate the tenant regardless of network connectivity. Verify DNS configuration on the workstation and check with your network team. #### Check Certificate Trust SSL errors between the Credential Provider and the tenant will prevent authentication. Verify the tenant's certificate is trusted by the workstation: ```bash $url = "https://" Invoke-WebRequest -Uri $url -UseBasicParsing ``` If this returns a certificate error, ensure the root CA for the tenant certificate is in the workstation's Trusted Root Certification Authorities store. #### Proxy Environments If the workstation connects to the internet through a proxy, the Credential Provider must be configured to route requests through it: 1. Open the registry editor and navigate to: ```bash HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos\1KosmosCredentialProvider ``` 2. Set the `ProxyServer` value to your proxy address and port (e.g., `http://proxy.corp.example.com:8080`). 3. Restart the Credential Provider service. ### Installation Issues | Issue | Likely Cause | Resolution | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Installer exits immediately with no error | Insufficient privileges | Run the installer as Local Administrator or via an elevated command prompt | | MSI installation returns error 1603 | Conflicting software; previous installation not cleanly removed; .NET dependency missing | Review the MSI log (`/l*v`); check for residual files in `C:\Program Files\1Kosmos\1KosmosCredentialProvider`; run `msiexec /x` on the previous version before re-installing | | 1Kosmos tile does not appear after installation | Installation completed but reboot not performed; Credential Provider service not running | Reboot the workstation; verify the Credential Provider service is running | | Installation succeeds but `REGCONFIG.ini` settings not applied | `REGCONFIG.ini` was not in the same directory as the installer at the time of installation | Place `REGCONFIG.ini` alongside the installer and re-run; verify the tenant URL and tenant ID values in the file are correct | | EXE installer silent flag not recognised | Incorrect flag casing or wrong installer framework | Verify the `/S` flag is uppercase; see Uninstall EXE for flag reference; contact 1Kosmos support if the flag is not recognised | ### Authentication Issues | Issue | Likely Cause | Resolution | | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | 1Kosmos tile missing on login screen | Credential Provider service not running; installation incomplete; reboot not performed after install or uninstall | Check service status; verify installation directory exists; reboot the workstation | | User not found or authentication rejected | User's AD account not synced to the 1Kosmos tenant; UPN format mismatch | Verify the user exists in AdminX under **Users > All Users**; confirm the UPN format matches between AD and the tenant | | No MFA prompt - user logs in with password only | No Adaptive Auth Journey assigned to the user or machine | Verify the user is within the assignment scope of a published journey in **Applications > Windows MFA > Adaptive Auth Journeys** | | MFA prompt appears but all methods fail | Tenant connectivity lost; user not enrolled in the required method | Test connectivity using the steps in [Connectivity Diagnostics](#connectivity-diagnostics); verify enrollment in AdminX | | Authentication succeeds on mobile but Windows session does not unlock | Session timeout between mobile approval and Windows response; Credential Provider service crashed | Ensure the user completes the mobile step promptly; restart the Credential Provider service; retry | | Push / QR / OTP options not appearing | Journey not configured with those methods; AD profile attributes missing for OTP | Review the assigned journey in AdminX; for OTP, verify `mobile` and `mail` attributes on the AD profile | ### Windows Login Screen Issues | Issue | Likely Cause | Resolution | | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Login screen shows no credential providers at all | Windows credential provider registration corrupted | Run `sfc /scannow` from an elevated command prompt; reboot; if unresolved, re-install the agent | | Both 1Kosmos tile and Windows password tile visible when only one is expected | `DisablePwdOnCredUI` or related registry key not configured | See Configuration Reference for registry keys controlling provider visibility | | Login screen freezes after clicking 1Kosmos tile | Credential Provider service deadlock; tenant unreachable causing long timeout | Restart the Credential Provider service; test tenant connectivity; review logs for timeout errors | | Tile branding shows "1Kosmos" instead of "1KOSMOS" | Agent version prior to v2.4.0.0 installed | Update the agent to v2.4.0.0 or later; the tile label was updated in that release | *** ### Group Policy and Registry Issues | Issue | Likely Cause | Resolution | | ---------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Registry settings applied via GPO not taking effect | GPO not linked to correct OU; GPO not refreshed on workstation | Run `gpupdate /force` on the workstation; verify GPO link and scope using `gpresult /h report.html` | | `REGCONFIG.ini` values overwritten after GPO refresh | GPO is applying conflicting registry values | Audit GPO registry settings for the `HKEY_LOCAL_MACHINE\SOFTWARE\1Kosmos\1KosmosCredentialProvider` path; resolve conflicts between `REGCONFIG.ini`-applied values and GPO-applied values | | Registry key changes not reflected at login screen | Credential Provider caches configuration at service start | Restart the Credential Provider service after making registry changes | ### Diagnostic Checklist Use this checklist when investigating any login or authentication failure before escalating. | Step | Check | | ---- | ------------------------------------------------------------------------------------------------------- | | 1 | Credential Provider service is running (`Get-Service -Name "1KosmosCredentialProvider"`) | | 2 | Workstation can reach the tenant on port 443 (`Test-NetConnection`) | | 3 | DNS resolves the tenant hostname (`Resolve-DnsName`) | | 4 | No certificate errors when accessing the tenant URL | | 5 | User exists in AdminX under **Users > All Users** | | 6 | An Adaptive Auth Journey is published and assigned to the user | | 7 | Log files exist and contain recent entries in `C:\Program Files\1Kosmos\1KosmosCredentialProvider\Logs` | | 8 | No errors in Windows Event Viewer under **Windows Logs > Application** from `1KosmosCredentialProvider` | | 9 | Workstation has been rebooted since last installation or configuration change | | 10 | Agent version is current - check **Settings > Apps** for the installed version | *** ### Known Limitations | Limitation | Detail | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Offline MFA | Only cached PIN (Behavior Auth & PIN) and cached Windows password are available offline; all other methods require network connectivity to the tenant | | RDP without agent on destination | MFA cannot be enforced at the destination server if the Credential Provider is not installed there; see [RDP / Remote Desktop](/authentication/windows-workstation-mfa/deployment-scenarios/rdp) | | Entra ID joined machines | Not yet supported; see[ Entra ID Joined Machines](/authentication/windows-workstation-mfa/deployment-scenarios/entra-joined-workstations) | | Local account exclusions | Only local accounts can be excluded from MFA enforcement via `ExcludedAccounts`; domain accounts cannot be excluded | | Maximum offline PIN attempts | Cached PIN is permanently cleared after 3 failed offline attempts; online re-authentication is required to restore it | # Release Notes for Windows Workstation MFA Release history for the 1Kosmos Workstation Login Credential Provider for Windows *** ## Overview Release notes for the 1Kosmos Workstation Login Credential Provider for Windows. Versions are listed in reverse chronological order, with the most recent release at the top. {% hint style="info" %} The Credential Provider was rebranded from "BlockID" to "1Kosmos" beginning in release 2.4.0.0. References to "BlockID" in earlier releases reflect the product naming at the time of release. {% endhint %} ### 2.4.6.0 *July 17, 2026* #### New Features **MFA Support for Local Windows Users** Community administrators can now enforce multi-factor authentication (MFA) for local Windows users. Previously, local users without an alias mapping bypassed all MFA and proceeded directly to password-only login. When enabled, local users are required to complete MFA before entering their Windows password - online or offline. If a user is disabled on the platform, login is blocked. {% hint style="info" %} To enable this feature, reach out to your 1Kosmos representative. {% endhint %} **Configurable Maximum Offline PIN Attempts** The maximum number of incorrect offline PIN attempts allowed before PIN input is disabled is now configurable. Previously, this was fixed at 3 attempts. This setting is configurable via CaaS. If not configured, the default of 3 attempts applies. **Computer Name Display During Local Account Login** The login screen now displays the computer name when a local account login is detected. This helps IT administrators identify the machine without having to ask the user separately. **Rate Limit Support for OTP and Push Notifications** Rate limiting for OTP and push notifications is now extended to the Windows Credential Provider. When a user exceeds the allowed number of requests within a defined time window, the Credential Provider displays an error message indicating how long to wait before retrying. The rate limit error message is supported in English, French, Spanish, Portuguese, and German. **Improved Visibility into Workstation Lock Events** Workstation lock events now include additional information to identify whether the lock was triggered automatically by the Windows Credential Provider, by the user manually, or due to inactivity. Community administrators can navigate to events in the AdminX interface to distinguish security-enforced locks from user-initiated or system locks. **Configurable Pre-Lock Notification Countdown for Offline PIN Login** The countdown duration before workstation lock on network restoration (introduced in Release v2.4.5) is now configurable. The notification message dynamically reflects the configured countdown value. This setting is configurable via CaaS. If not configured, the default of 5 seconds applies. #### Bug Fixes * Fixed an issue where offline OTP validation failed when the username was entered in lowercase, while the same username in uppercase authenticated successfully. * Fixed an issue where OS name and version fields in Windows Credential Provider login events displayed incorrect or inconsistent values. ### 2.4.5.0 *June 25, 2026* #### New Features **Complete Session Activity Tracking** The Windows Credential Provider now captures and reports all session lifecycle events to the 1Kosmos platform, including login, unlock, workstation lock, and session logoff. Previously, only authentication outcomes were reported. With this update, organizations can accurately monitor session activity across the full user lifecycle, supporting use cases such as auditing session behavior, calculating active versus inactive periods, and identifying productivity patterns. Events are reliably delivered even across network interruptions, with offline events queued and emitted in chronological order once connectivity is restored. **Enhanced Security During Offline PIN Login** When a user logs in using offline PIN due to platform unavailability, the Windows Credential Provider now monitors for network restoration in the background. Once connectivity is confirmed, the workstation displays a notification and locks automatically, requiring the user to authenticate using the configured authentication journey. Offline PIN login activity is now recorded and synchronized to the platform once connectivity is restored, closing the audit gap where offline logins were previously unrecorded. #### Security Enhancements * Strengthened filesystem permissions and access controls for privileged service communication, reducing the risk of unauthorized local access. * Strengthened binary integrity protections for Windows authentication components, improving resistance to unauthorized modification. ### 2.4.4.0 *May 28, 2026* #### New Features **Multilingual Support for CP UI and Behavior Authentication** The 1Kosmos Credential Provider now supports Spanish, Portuguese, French, and German. The Credential Provider automatically detects the Windows OS language setting on the user's workstation and displays the interface in the corresponding supported language, with no action required from the end-user. Administrators can also enforce a specific display language across all managed devices, regardless of individual workstation locale settings. **Microsoft TPM Virtual Smart Card Support for Windows Login** The 1Kosmos Credential Provider now supports Microsoft TPM Virtual Smart Card (VSC)-based authentication, improving Windows passwordless login performance in shared workstation environments. Previously, authentication times were approximately 20 seconds per login. With TPM VSC support enabled, user certificates are securely cached in the device TPM after the initial login, reducing subsequent login times to approximately 3 to 4 seconds. If TPM hardware is unavailable or initialization fails, authentication automatically falls back to the existing 1Kosmos login flow, ensuring uninterrupted access. ### 2.4.3.0 *May 19, 2026* #### Bug Fixes **Force Enrollment for Behavior Auth and PIN** Fixed an issue where users could bypass Behavior Auth and PIN enrollment by clicking a "Skip Enrollment & Login" link on the enrollment screens. Organizations requiring all users to enroll were affected as this allowed users to proceed without setting up their authentication factors. Administrators can now enforce mandatory enrollment, ensuring users complete setup before logging in. This setting is configurable via CaaS. **Case-Insensitive Username for Offline Authentication** Fixed an issue where offline authentication failed when the username was entered in a different case than what was registered. For example, a user registered as "JohnDoe" would fail authentication when typing "johndoe" or "JOHNDOE". Offline authentication now performs case-insensitive username comparison, consistent with standard Windows login behavior. No configuration is required. ### 2.4.2.0 *May 12, 2026* #### Enhancements **LiveID authentication performance optimization.** This release significantly reduces delays during camera initialization and login for the LiveID authentication flow. Impact: * Camera initialization reduced from approximately 8 seconds to 4–5 milliseconds. * Approximately 99.9% performance improvement. * Faster and more consistent login experience. {% hint style="info" %} Smartcard and PKINIT login latency depend on Windows processing and network conditions and are not impacted by this change. {% endhint %} **Security fixes.** Additional security enhancements have been implemented to strengthen protection in the Windows Workstation MFA Agent. ### 2.4.0.0 *March 31, 2026* #### New Features **Rebranding to 1Kosmos.** The Windows Workstation MFA Agent has been rebranded to align with the updated 1Kosmos brand identity. All user-facing references to "BlockID" have been replaced with 1Kosmos branding. Key changes: * Removal of "BlockID" terminology across the Credential Provider. * Updated logos and visual elements with 1Kosmos branding across login screens, dialogs, and configuration interfaces. **Dependency check enhancement for the installer.** Enhanced dependency validation has been added to the EXE installer, which now checks for required .NET Framework versions and automatically installs missing dependencies during setup. The 1Kosmos Credential Provider continues to support two installation formats: * **EXE installer** - Performs dependency checks and automatically installs missing prerequisites (such as .NET Framework 4.8). * **MSI installer** - Requires all prerequisites to be installed manually. If dependencies are missing, the installation will not proceed. {% hint style="warning" %} Ensure required dependencies are installed before using the MSI installer. {% endhint %} **Kerberos service ticket retrieval fix.** Fixed an issue where Kerberos service ticket retrieval failed after login when the smart card was ejected. The Credential Provider now supports configurable smart card ejection behavior to maintain credential context. The following registry settings are available to control smart card ejection behavior (default: enabled): * `DisableSmartcardOnLogin` (DWORD) — default: 1 * `DisableSmartcardOnCredUI` (DWORD) — default: 1 **LiveID performance enhancement — early camera warm-up.** Implemented early camera initialization for LiveID authentication to reduce authentication time and improve user experience. Benefits: * Faster authentication response time. * Reduced wait time for biometric authentication. #### Bug Fixes * Fixed an issue where PIN-based login was not functioning correctly when the machine was offline and Behavioral Authentication was configured. ### 2.3.0.0 *March 18, 2026* #### New Features **MSI-based installation support.** The V2 Credential Provider can now be installed using an MSI package, enabling both interactive (UI-based) and silent installations. For more information, see [Installation Using MSI Package.](/authentication/windows-workstation-mfa/installation/install-using-msi) ### 2.2.0.0 *March 13, 2026* #### New Features **Prevent workstation lockouts with helpdesk passcode fallback.** Users who fail to authenticate through Behavioral Authentication + PIN after a configurable number of attempts can now access a fallback authentication journey to regain access to their Windows workstation. In this flow, users contact the Helpdesk to obtain a temporary passcode, allowing them to securely complete login, reduce the risk of being locked out, and maintain productivity. After retrieving the passcode, users can either log in directly or reset one enrolled authentication factor (Behavioral Authentication or PIN), if enabled and allowed for their account. Community administrators must configure the fallback authentication journey in AdminX and ensure a primary authentication journey (for example, Behavioral Authentication + PIN, or Password + OTP) is configured. If no authentication journey is defined, the fallback option will not be presented to users. For more information, see[ Fallback Authentication](/authentication/windows-workstation-mfa/authentication-methods/fallback-authentication). {% hint style="info" %} * Supported authentication factors: Behavior Authentication, PIN, and OTP. * Supported Credential Provider version: 2.2.0.0. {% endhint %} **Offline authentication for users without mobile OTP.** Windows workstation users who do not have access to a mobile device or camera can now authenticate using a locally stored PIN when offline. This enables secure workstation access without requiring the 1Kosmos mobile app or network connectivity. When the device is offline, the Credential Provider detects the loss of connectivity and presents available authentication options based on what is cached on the device: * PIN login, if a PIN is cached. * OTP login, if a CommunitySeed is available. * Both options, if both are available. For security, offline PIN authentication allows a maximum of three attempts. After the third failed attempt, the cached PIN is cleared, and the user must reconnect to the internet to authenticate. ### 2.1.5.3 *February 14, 2026* #### New Features **Registry-based switches to disable the 1Kosmos Credential Provider.** Administrators can now dynamically disable the v2 Credential Provider without requiring uninstallation. Two new registry-based configuration switches control the visibility of the 1Kosmos Credential Provider during specific authentication flows. New registry settings: * **`Disable1KosmosOnLogin`** — when set to `1`, the 1Kosmos Credential Provider is hidden during login and unlock flows. * **`Disable1KosmosOnCredUI`** — when set to `1`, the 1Kosmos Credential Provider is excluded from CredUI flows and will not appear in credential prompts. Impact: * No system restart or uninstallation is required to disable the Credential Provider. * Provides administrators with greater operational flexibility. * Ensures non-disruptive fallback to other credential providers when disabled. ### 2.1.5.2 *January 28, 2026* #### Enhancements **Enhanced `installer.exe` with custom command-line configuration support.** The Windows Workstation MFA Agent installer now supports custom configuration through command-line parameters during automated installation. This enhancement eliminates the need for external batch (BAT) scripts previously used to modify registry values and copy configuration files post-installation. By applying configuration directly during installation, the process is now more streamlined and secure. For more information, see[ Installation Using Command-Line Parameters.](/authentication/windows-workstation-mfa/installation/install-using-exe-legacy) ### 2.1.5.1 *January 8, 2026* #### Bug Fixes * Fixed an issue that prevented users from being signed in to Windows after successful LiveID face authentication. * Enhanced user validation during mobile authentication to ensure consistent behavior across all environments. ### 2.1.5.0 *November 26, 2025* #### New Features **Support for password-based shared account access.** Users who decline biometric consent can now authenticate on shared workstations using their primary account password. Once authenticated, they can select a shared account as before. Administrators can enable this through the new **Password for Shared Account Login** option in Windows MFA. For more information, see [Password-Based Authentication for Shared Accounts.](/authentication/windows-workstation-mfa/deployment-scenarios/shared-workstations) {% hint style="warning" %} * Users must upgrade their Windows Workstation MFA Agent to version 2.1.5.0 for this feature to function. * The existing FIDO shared account login journey must be re-saved to ensure compatibility with the new Windows Workstation MFA Agent. {% endhint %} **PIN lockout notifications.** The Windows Workstation MFA Agent now provides clear notifications when the behavior authentication PIN becomes temporarily locked after repeated incorrect attempts: {% hint style="info" %} *"Your PIN has been locked due to multiple incorrect PIN attempts. You can attempt using your PIN in x minutes."* {% endhint %} These updates help users better understand lockouts and reduce login confusion. **Username displayed in UWL2 session.** Previously, during login, users could see a different persona in the mobile app than the username they were attempting to authenticate, because the Windows Workstation MFA Agent did not send the requested username to the app. This could make it appear as though authentication had occurred for the wrong user. The UWL2 session now includes the username being authenticated and identifies the session as an authentication request, ensuring the mobile app displays the correct user during login. ### 2.1.4.0 *November 7, 2025* #### Enhancements * Added detailed FIDO-related debug logs to assist in troubleshooting and observability. A new log file, **`BlockIDFIDOLogs.txt`**, is now created in the Logs folder. * Security enhancements have been implemented to improve protection and strengthen overall system resilience in the Windows Workstation MFA Agent. #### Bug Fixes * Fixed an issue where the BlockID Credential Provider would not appear as an available option on the LogonUI screen after the workstation resumed from sleep. * Fixed an issue where, during RDP login, the message "Something went wrong. Please contact your administrator." was displayed after entering the password in the Microsoft native Credential Provider and submitting the OTP in the 1Kosmos Credential Provider. ### 2.1.3.0 *October 17, 2025* #### New Features **Support for filtering the password provider in the Windows Workstation MFA Agent.** Administrators can now independently enable or disable the password provider for Login/Unlock and CredUI flows, allowing MFA to be enforced at the workstation login screen while retaining password-based access where still required (for example, RDP and Run As). For more information, see [Configuring Password Provider Visibility.](/authentication/windows-workstation-mfa/authentication-methods/run-as-and-uac) **Ability to clear the last-used provider.** The Windows Workstation MFA Agent can now prevent the OS from automatically selecting the last-used credential provider on subsequent logins, allowing users to choose a different provider or delay login. **Request ID in logging.** Added support for displaying `requestId` in system logs to improve traceability and debugging. #### Bug Fixes * Fixed an issue where the screen flickered during window transitions, resulting in a poor user experience. * Fixed a crash in the Windows Workstation MFA Agent when logging in with a local user that shares the same username as a directory user. * Fixed an issue causing frequent `LogonUI.exe` crashes in Jefferies VDI environments following the BlockID Credential Provider upgrade. The crashes were due to invalid memory access within the Credential Provider module during user logon. ### 2.1.2.0 *September 5, 2025* #### New Features **Enroll and authenticate to Windows using typing biometrics and PIN.** Two additional authentication factors are now supported: * **Behavior Authentication** — recognizes a user by their unique typing rhythm, speed, and key-press patterns. This helps verify identity without additional credentials. * **User PIN** — allows a user to set and use their own Personal Identification Number. Both can be enrolled through the Windows Workstation MFA Agent and used as authentication methods for logging in to Windows. This is particularly beneficial in environments where login requires DSS-compliant passwords (14–16 characters), which can be difficult to remember. Users can also enroll a PIN as an additional measure to authenticate and log in to their workstation securely. By reducing the need for frequent password changes, this feature offers a more seamless authentication experience. For more information, see [Behavior Authentication](/authentication/windows-workstation-mfa/authentication-methods/behavior-authentication). **Security enhancement — authenticated JWT for SCEP and enrollments.** The platform now provides the Windows Workstation MFA Agent with a JWT containing all the completed authentication factors for the user. This JWT is then used to fetch SCEP or for enrollment. **Enhanced Generate OTP API.** The Windows Workstation MFA Agent now supports OTP generation via Email, SMS, and Voice when a user's mobile device is not registered or enrolled. ### 2.0.9.0 *June 30, 2025* #### New Features * Shared account logins now use the username fetched from the CyberArk proxy, instead of relying on the displayed username on the shared account window. The CyberArk proxy applies a transformation script to retrieve the username in UPN format. #### Bug Fixes * Fixed an issue where Windows LiveID incorrectly validated a face even when it was placed outside the camera view. ### 2.0.8.0 *May 15, 2025* #### New Features **Support for MFA on local account logins.** The Credential Provider now supports displaying multi-factor authentication (MFA) methods for both local and remote account logins. To enable MFA for a local user, the local account must be added as an alias. For more information, see[ Offline Login.](/authentication/windows-workstation-mfa/deployment-scenarios/offline-scenario) **Introduced CyberArk Proxy component.** Previously, the Windows Workstation MFA Agent sent requests directly to CyberArk to retrieve service account credentials. Under high concurrency (approximately 400 users), the service account would become locked out due to CyberArk throttling, causing login disruptions. Even at lower loads, API throttling produced slow response times (approximately 5 seconds), negatively impacting user experience and business continuity. To address this, 1Kosmos has introduced a new on-premises proxy component for Windows, macOS, and Linux systems. The proxy handles the connection to CyberArk, offloading direct API calls from each workstation. On Windows it runs as a service; on macOS and Linux it operates via the command line. Before starting the service, administrators must configure CyberArk credentials, including a valid service account, to streamline password retrieval and prevent repeated logins. For more information, see [CyberArk Proxy Login Using Shared Accounts.](/authentication/windows-workstation-mfa/deployment-scenarios/shared-workstations) {% hint style="info" %} Both direct and proxy-based implementations are supported. Customers can choose the model that best fits their environment. {% endhint %} #### Security * Addressed a potential replay attack vector in which an attacker with physical access to a workstation could intercept and replay API responses from the platform to gain unauthorized access. The scenario required the attacker to install a proxy tool on the target machine to capture network traffic, making it a complex and unlikely attack path. Safeguards have now been implemented to mitigate this risk and enhance overall platform security. #### Bug Fixes * Resolved an issue where cURL requests had inconsistent timeout behavior on the loading screen: * When internet connectivity was available, requests timed out as expected. * When a proxy was enabled but no internet connection was present, requests experienced prolonged delays. ### 2.0.7.0 *May 1, 2025* #### New Features **Passwordless authentication for RDP and Run As use cases.** Users can now authenticate passwordlessly when running applications as an administrator or as a different user. **Login to Windows using UserPrincipalName (UPN).** User login is now supported using both the SAM account name and the User Principal Name (UPN). To enable UPN-based login, administrators must map the user's SAM account name to the BlockID attribute (`winuserattribute`). **Enhanced `E_LOGIN_SUCCEEDED` and `E_LOGIN_FAILED` event details.** When a user logs in via QR, Push, or FIDO mechanisms, both events now include device details and the authenticator used during authentication: * `device_id` * `auth_device_os` * `auth_device_name` * `auth_device_app_name` * `auth_device_app_version` * `auth_device_ip_address` * `auth_device_os_type` * `auth_device_make` * `auth_device_model` #### Miscellaneous * During installation of the Windows Workstation MFA Agent, the default idle timeout value has been updated to 75 seconds to enhance session security and responsiveness. ### 2.0.6.0 *February 24, 2025* #### New Features **Send OTP via SMS, email, and voice call.** Users are now shown options to send OTP via SMS, email, or voice call if their profile has an associated phone number and/or email address. {% hint style="info" %} * The phone number used for SMS and voice call is the primary phone number associated with the profile. * OTP delivery via these channels is enabled by default. Voice call and SMS options are displayed if a phone number is associated with the user profile; email OTP is shown if an email address is associated. * No control over enabling individual SMS, email, or voice OTP options is currently available. {% endhint %} #### Miscellaneous * Added a feedback message for users after a QR code is scanned and authentication is approved on the mobile device. * Added a feedback message to inform users when their account is locked due to exceeding the maximum number of incorrect OTP entries. #### Bug Fixes * Resolved an issue where FIDO login would occasionally fail. ### 2.0.5.0 *December 20, 2024* #### New Features **Notifying users during QR scan validation.** When users scan the QR code on the login screen, the Windows Workstation MFA Agent now informs them that the scanned QR code is being validated, providing a smoother user experience. **Enhanced logging for PII protection.** Logs have been updated to prevent the display of users' PII data. **Error message on maximum incorrect OTP attempts.** The Windows Workstation MFA Agent now displays an error message when a user exceeds the maximum number of incorrect OTP attempts, notifying them that the account is locked and they can try again later. #### Bug Fixes * Fixed an issue where users were unable to log in to the workstation with a registered FIDO key. * Fixed an issue where log files were being created in the default location despite a custom install path being selected. ### 2.0.4.0 *December 13, 2024* #### New Features * Support for the new consent screen on mobile. * Support for number-challenge push notifications. * Custom branding capability. * Support for direct upgrade from V1 to V2 Credential Provider. * Miscellaneous UI-related bug fixes. ### 2.0.3.1 *October 12, 2024* #### Bug Fixes * Fixed an issue where smartcard login via BlockID (for example, Push) failed after session lock in Citrix VDI environments with V2 Credential Provider 2.0.3.0, displaying "The username or password is incorrect" after a prolonged loading screen. ### 2.0.3.0 *September 30, 2024* #### New Features * Support for local account login. * Support for shared accounts. * Stability improvements and UX fixes. ### 2.0.2.0 *August 30, 2024* #### New Features **Allow local accounts to log in to the workstation.** Users can now log in to a workstation using a local account through the BlockID app. The Credential Provider intelligently identifies whether the selected account is a local account or a domain account. This enables workstation access without requiring a network connection and provides flexibility and resilience, ensuring users have reliable access under a variety of circumstances. **Determine users using shared accounts in the V2 Credential Provider.** The Windows V2 Credential Provider has been enhanced to identify the user behind a shared account login. A new **Shared Account** option has been added to the Sign In — Choose an Authentication Method screen. The Shared Account option must be configured in the database. When a user selects this option, a list of shared accounts associated with the user is displayed; the user can then choose the appropriate account and log in. This enables organizations to trace which user is operating a shared account and helps with shared-account management. ### 2.00.00 *July 10, 2024* #### New Features * Introduced a new Credential Provider built on the Windows Credential Provider V2 framework, enabling user authentication using a combination of password and one-time passcode (OTP). For more information, see [Windows Workstation MFA Agent.](/authentication/windows-workstation-mfa/overview) ### 1.09.01 *March 22, 2024* #### New Features * Enabled password redirection from the host workstation, allowing OTP, QR, and Push mechanisms to be used on a remote machine when connecting through RDP. * OTP and FIDO options have been integrated into the **Switch User** lock screen. BlockID now supports Push notifications, OTP, and FIDO keys for unlocking the workstation. #### Bug Fixes * Fixed an issue where multiple QR dialogs would appear on the login screen on some workstations. * Fixed an issue where cancellation of QR and Push notification would not work in certain cases. ### 1.09.00 *January 31, 2024* #### New Features * Introduced functionality for using password and OTP MFA through the **More choices** option on the Windows authentication prompt for applications. * Added the ability to pre-populate passwords on the remote workstation's login screen when password redirects occur from the host workstation. #### Enhancements * QR and Push notification login mechanisms are now configurable, allowing users to easily enable or disable these features as needed. * The OTP mechanism is now accessible on the Windows lock screen. Users can enable this from the BlockID Configurator. * The automated installation script has been updated to accommodate the new configurations introduced. ### 1.08.07.01 *November 22, 2023* #### Enhancements * Removed validations on the tenant tag in the BlockID Configurator. * Resolved an issue where the BlockID Credential Provider would crash when an invalid user attempted to log in with a FIDO key. ### 1.08.07 *October 19, 2023* #### Enhancements * Eliminated the requirement for an initial mobile login as a prerequisite for enabling authentication through FIDO keys. Because the FIDO assertion is produced using the 1Kosmos platform, the workstation must be connected to the internet to use this feature. * Added configuration to enable or disable the PIN prompt for FIDO key logins on the lock screen. * Updated the behavior of the UV and UP flags for FIDO login on the Credential Provider based on the configuration received from the API. ### 1.08.06 *September 21, 2023* #### Bug Fixes * Cross-signed the Credential Provider DLLs through Microsoft. This was required to resolve an issue on Windows 11 22H2 workstations where LSA, when enabled, would block the 1Kosmos smartcard driver from loading, resulting in authentication failures. ### 1.08.05 *August 31, 2023* #### Bug Fixes * Resolved an issue where logins would fail because the communication protocol was not initialized in certain situations. This issue was intermittent, and users would see a generic Windows OS error message: **Username or password is incorrect**. ### 1.08.04 *August 10, 2023* #### Enhancements * Implemented a cache manager to better manage the local cache. The cache manager handles the API endpoint caching and associated public keys for a maximum of 24 hours, improving overall performance and login time. ### 1.08.03 *July 20, 2023* #### Enhancements * Smart Card Driver DLL files are now signed using a new code-signing certificate. * Logging functionality in the BlockID Credential Provider has been expanded. * Updated logic to identify PAC URLs. URLs are now treated as PAC URLs if the address contains `.pac`. This allows the BlockID Credential Provider to recognize PAC URLs that also have a policy parameter — for example, `http://webproxy.local:3128/proxy.pac?p=15df7tpd5` is now recognized as a PAC URL by the Credential Provider. #### Bug Fixes * Corrected a bug where a connection check through the proxy was not taking place. ### 1.08.00 *May 18, 2023* #### Enhancements * Added a timeout to the BlockID Credential Provider when establishing a connection through a proxy to check system connectivity status and refresh login tiles. #### Bug Fixes * Fixed an issue where remote connections through BlockID RDPHelper were failing. ### 1.07.05 *April 27, 2023* #### New Features **FIDO2-based authentication using security keys.** FIDO2 authentication using hardware security keys (for example, YubiKey) has been added to the BlockID Credential Provider. Users can enroll their security key using the AdminX control panel. When using FIDO2 login, the Credential Provider sends a FIDO challenge to the security key using the CTAP2 protocol. The Credential Provider validates the signed challenge returned by the key and allows the user to log in after successful verification. #### Enhancements * Updated the label for passwordless login using QR to **QR Login** and resized the dialog for a better user experience. #### Bug Fixes * Fixed an issue where BlockID Credential Provider smart card login was failing intermittently. ### 1.07.04 *February 17, 2023* #### Enhancements * The BlockID Credential Provider now caches service directory endpoints to avoid making repeated API calls for fetching data, improving overall performance and login time. #### Bug Fixes * Fixed an issue where the BlockID Credential Provider tiles were repeating in cases of multiple user logins through RDP on the same workstation. ### 1.07.03 *January 25, 2023* #### Enhancements * Users can now choose whether to enable or disable automatic restarts for workstations when installing the BlockID Credential Provider using batch scripts. Users can opt to restart the workstation by supplying a restart flag. * BlockID now has a setting to configure **Login with FIDO** mode. Configuration for this setting can also be automated when running the installation and configuration script. * The BlockID Credential Provider now updates its available login options when detecting a change in internet connectivity. When online, QR Code and Push Notification login options are available; when offline, only OTP login (if enabled in the BlockID Credential Provider) is available. #### Bug Fixes * Removed test-suite executables `FakeWinlogon.exe` and `NativeLibTest.exe` from the BlockID installer package. These simulators served no purpose to end users and have been removed. * Fixed an issue where offline authentication using OTP failed after a proxy was set. * Fixed an issue where the BlockID service did not start, causing the workstation screen to blur and rendering the login page inaccessible. ### 1.07.02 *December 7, 2022* #### New Features **FIDO2-based authentication for the BlockID Credential Provider.** FIDO2-based authentication has been integrated into the BlockID Credential Provider. Users can now enroll using the BlockID Mobile Application. With FIDO2 login, the BlockID Credential Provider sends a FIDO2 challenge to the BlockID Mobile Application for signing. The Credential Provider then validates the signed challenge, and after successful account verification, the user is logged in. #### Enhancements * BlockID now checks the expiration time of cached user certificates before authenticating the user when the machine is offline. #### Bug Fixes * Fixed an issue where proxy settings were not being used when creating new user sessions. * Fixed an issue where the BlockID tile did not appear on the login screen when the VC++ Redistributable package was not installed on the workstation. ### 1.07.01 *September 1, 2022* #### New Features **Forced passwordless authentication.** Administrators can now enforce passwordless authentication on workstations. This disables the default password provider, leaving users with the option to log in via QR, Push notifications, OTP, and MFA. Forced passwordless can be enabled using the **Disable Windows Password Provider** option in the Advanced tab. **CAD (Ctrl+Alt+Delete) requirement.** Requiring CAD (Ctrl + Alt + Delete) before sign-in ensures communication through a trusted path when credentials are provided, protecting users from attacks that attempt to intercept credentials at sign-in. This can be enabled using the **Enforce Ctrl + Alt + Del** option in the Advanced tab of the BlockID Configurator. CAD is enabled by default when the forced passwordless option is enabled. #### Enhancements * Ability to re-initialize QR or Push notification after an error or when the user cancels the login attempt. #### Bug Fixes * Fixed an issue where MFA (username + password + OTP) would not work in certain cases when the workstation was offline. ### 1.07.00 *August 22, 2022* #### Enhancements * The BlockID Credential Provider now caches the session's services and community public keys to avoid making repeated API calls for fetching them. This improves overall performance when using the platform microservice for user sessions. * The BlockID Credential Provider now verifies whether the user account is linked to the DID. ### 1.06.02 *August 1, 2022* #### New Features **MFA login (User ID + Password + OTP).** The BlockID Credential Provider now supports using the password factor along with OTP for added security. Users are challenged for their username, password, and Workstation OTP (from the BlockID mobile app). This can be enabled using the **Allow Password Factor** setting in the BlockID Configurator. **Support for BlockID OTP from the BlockID mobile app.** Users can now log in to their workstations using the BlockID OTP displayed on the main screen of the BlockID Mobile App. BlockID OTP is available by default and can be used when the workstation is online. If the administrator enables hardware tokens for OTP generation, this feature can be disabled. **Support for hardware OTP tokens.** BlockID can now be configured to use OTPs from enterprise-issued hardware tokens such as OneSpan. This is enabled using the **Use Hardware OTP** setting in the BlockID Configurator. Hardware OTP authentication is available only when the workstation is online. #### Enhancements * **Support for UWL 2.0 sessions** — internal enhancement in which the BlockID Credential Provider uses the platform microservice for user session generation. This enables and supplements the audit trail of user activity. #### Bug Fixes * Fixed an issue where users could not cancel QR or Push notification on workstations or remote machines running Windows Server 2012 and Windows 8/8.1. ### 1.06.01 *May 30, 2022* #### New Features **Online login supported via OTP.** BlockID has extended the OTP authentication feature for use when the workstation is online. The setting can be enabled by the administrator using the **Enable Online OTP** setting in the BlockID Configurator. The Workstation OTP available in the BlockID App can be used to generate the time-based OTP for login. Users now have the choice of QR, Push notification, and Workstation OTP for logging in. #### Enhancements * BlockID now has configurations to enable Offline and/or Online OTP modes, as well as the ability to add custom images and labels for the OTP tiles on the login screen. These configurations can also be automated using the installation and configuration script. * Updated icons for the Configurator, RDPHelper, and installer EXE. ### 1.06.00 *May 13, 2022* #### New Features **Offline login supported via OTP.** The BlockID Credential Provider now supports login via OTP as the authentication factor when the workstation is offline. BlockID detects when the workstation is not connected and challenges the user to enter the Workstation OTP from the BlockID mobile application. To use the Workstation OTP, the user must have logged in using BlockID QR or Push notification at least once previously. #### Deprecated Functionality * Deprecated the reverse QR scanning feature for offline login. ### 1.04.00 *August 16, 2021* #### Bug Fixes * Removed the "BlockID Initialization..." message on Windows start-up. Previously, if the service did not start during machine start-up for a considerable time, the Credential Provider waited with this message, which could incorrectly suggest that the delay was caused by BlockID. ### 1.03.01 — MSI *July 19, 2021* #### New Features **Install BlockID via GPO.** An MSI file was added alongside the existing BlockID Credential Provider installation executable. This enables administrators to install BlockID via GPO. ### 1.03.01 *June 11, 2021* #### New Features **Optional deny credential passthrough for RDP.** A flag was added to the BlockID Configurator to deny credential passthrough for RDP connections. When the flag is checked, credentials passthrough is disabled on the remote machine (RDP). New configuration to deny credential passthrough has been added to the automatic installation and configuration script. **Disabled default Windows Smart Card Credential Provider in the registry.** The default Windows smart card credential provider has been disabled in the registry to prevent users from using PIN on remote workstations to log in when using RDP. ### 1.03.00 *April 17, 2021* #### Bug Fixes * Fix to pass credentials in case of RDP login using username/password and to stop the BlockID QR pop-up. #### Documentation Updates * Versioning of the Credential Provider has been moved to a new format representing the quarterly release numbers. # FAQs
Does the Windows Workstation MFA agent work with third-party disk encryption software or other credential providers? The Windows Workstation MFA agent permits the use of Trellix Drive Encryption (TDE) on workstations as per organizational policies and guidelines. However, you must update your registry settings to whitelist the TDE, as third-party credential providers will be blocked during system startup or restart.
Does the Windows Workstation MFA agent work with third-party disk encryption software or other credential providers? The Windows Workstation MFA agent permits the use of Trellix Drive Encryption (TDE) on workstations as per organizational policies and guidelines. However, you must update your registry settings to whitelist the TDE, as third-party credential providers will be blocked during system startup or restart.
Which Vault does the Windows Workstation MFA agent support? The Windows Workstation MFA agent supports fetching passwords for service accounts only from CyberArk vaults.
Where do I configure the Vault details? You can configure the CyberArk connection details in the Windows Workstation MFA agent registry. This includes the vault URL, vault service account, and vault credentials. On the next launch, after vault details are updated, the 1Kosmos Windows MFA agent will read the data from the registry and encrypt data. Registry Path: `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{90576E81-DDF8-4E8E-91E2-CA3A9CE52410}`
How do I update the registry? The registry can be updated through SCCM / GPO policy by the organization OR can be handled through the **BlockIDInstaller.bat** script with the `-configure` directive.
# Overview Passwordless for Web Apps lets users access web applications without entering a password. 1Kosmos acts as the Identity Provider (IdP) for web applications integrated using standard protocols.
User experience of Passwordless login for web apps
*** ### User Journey When a user accesses a web application protected by 1Kosmos: {% stepper %} {% step %} The user opens the web application. {% endstep %} {% step %} The application redirects the user to 1Kosmos for authentication. {% endstep %} {% step %} 1Kosmos authenticates the user using one of the supported methods. {% endstep %} {% step %} 1Kosmos returns an authentication response (an OIDC ID token, SAML assertion, or WS-Fed token) to the web application. {% endstep %} {% step %} The user is logged in to the web application. {% endstep %} {% endstepper %} ### 1Kosmos as Identity Provider or Service Provider For OIDC integrations, 1Kosmos can act as either: * **Identity Provider (IdP)** — 1Kosmos authenticates users and provides single sign-on to external web applications. * **Service Provider (SP)** — 1Kosmos consumes authentication from another SSO solution (such as ForgeRock, Okta, IBM Tivoli Access Manager, Oracle Access Manager, or CA SiteMinder). The external IdP authenticates the user and returns an OIDC token to 1Kosmos. For SAML integrations, 1Kosmos acts as the **Identity Provider (IdP)**, providing single sign-on to external Service Provider applications. ### Core concepts #### User consent Users must give explicit permission for 1Kosmos to share their profile information with relying parties. Consent grants are persisted on the 1Kosmos platform — when an application requests a new access token, the user is not re-prompted if they have already consented to the specified scopes. Consent grants remain valid until the user manually revokes them or until the user, integration, authorization server, or scope is deactivated or deleted. #### Force re-authentication Community administrators can require users to re-authenticate when accessing a SAML or OIDC application, regardless of whether they are already logged in with the same authentication factors. This is controlled by the **Force Re-authentication** setting on each SAML or OIDC integration. By default, this setting is disabled. When enabled and a user opens the target application, they are redirected to the 1Kosmos Authentication page with their username pre-filled and must complete authentication again. The following events are generated during force re-authentication: * `E_SP_MODIFIED` * `E_LOGIN_SUCCEEDED` * `E_SP_REDIRECT_SUCCEEDED` #### Where integrations are managed All web app integrations are added and configured in **AdminX**, under **Applications → Add Application**. Existing OAuth 2.0 / OIDC community settings are viewable under **Settings → Authorization Server**. # Authentication Matrix The table below outlines the authentication modes supported across different login methods. Availability of each mode depends on how authentication journeys are configured. *** ### Supported Authentication Modes by Login Method | Login Method | Single Factor Authentication | Multi-Factor Authentication | | --------------------------- | ---------------------------- | --------------------------- | | FIDO Keys | ✅ | ✅ | | LiveID | ✅ | ✅ | | Behavioral Authentication | ❌ | ✅ | | PIN | ❌ | ✅ | | Service Account Login | ❌ | ✅ | | Orion Desktop Authenticator | ✅ | ✅ | | Hardware Tokens | ❌ | ✅ | | QR | ✅ | ✅ | | Push | ✅ | ✅ | ### How to Read This Matrix * **Single Factor Authentication**\ Users can authenticate without entering a password, using a single secure method such as biometrics, passkeys, or device-based authentication. * **Multi-Factor Authentication (MFA)**\ Users authenticate using a combination of factors, such as password + OTP, biometric + PIN, or device + approval. #### Important Notes {% hint style="info" %} Authentication methods are applied as part of configurable authentication journeys. {% endhint %} {% hint style="info" %} Some methods can be used independently for single factor authentication or combined with other login methods for multi-factor authentication. {% endhint %} {% hint style="info" %} PIN and OTP-based methods (including SMS, Email, Voice, app-generated codes, and hardware tokens) are reserved for use as second factors in two-factor (2FA) or multi-factor (MFA) authentication flows. {% endhint %} # Analytics The Analytics Dashboard gives Community Administrators a graphical overview of user activity across the tenant. Data can be filtered by today, last 7 days, last 30 days, or a custom date range. *** #### What's on the Dashboard **Summary metrics** at the top show four numbers for the selected period: | Metric | Description | | ------------------------ | ------------------------------------------------------ | | **Unique Users** | Users with at least one authentication | | **Total Logins** | All login attempts across all applications and methods | | **Failed Logins** | Number of failed login attempts | | **New Devices Enrolled** | Devices registered during the period | **Charts** below the summary provide a breakdown of activity: * **Successful Authentications** — logins over time, broken down by authentication method; toggle between numbers and percentage view * **Application Usage** — total logins per SAML and OIDC application * **Failed Logins** — failed login count with reasons for failure * **New Devices** — new device enrollments per day # Login Methods
Login with Password Password Reset
FIDO KeysFIDO Keys
LiveID (Biometric Authentication)LiveID (Biometric Authentication)
Behavioral AuthenticationBehavioral Authentication
Orion Desktop AuthenticatorOrion Desktop Authenticator
Hardware TokensHardware Tokens
# Password Reset 1Kosmos gives Community Administrators control over how end users reset forgotten passwords. *** ### Overview The configuration lives under **Authentication > Reset Password** in AdminX, where you can enable one or more reset methods depending on your organization's security requirements. ### Methods to Reset a Password * **Reset via AdminX** — sends a reset link by email, or a link combined with a passcode to the user's registered phone * **Reset via Mobile App** — allows users to reset directly from the 1Kosmos mobile app; must be explicitly enabled even if mobile resets were previously working * **Reset via Identity Verification** — users verify their identity using a government-issued document before resetting. You also choose the identifier users enter on the Forgot Password screen — either their **email address** or **username**. If username is selected, the reset link is sent to the email address associated with that account. Once configured, click **Save**. ### Resetting via AdminX When AdminX-based reset is enabled, users click **Forgot Password?** on the login screen and enter their email or username. From there, the flow depends on the method configured: * **Email link only** — user receives a reset link, clicks it, and sets a new password * **Email link + passcode** — user receives the link and also a passcode on their registered phone; both must be used to complete the reset {% hint style="info" %} The reset link is valid for **30 minutes**. If a user has multiple accounts tied to the same email address, they'll be prompted to select which account to reset. {% endhint %} **Event Logs** — `E_PWDRESET_SUCCEEDED` and `E_PWDRESET_FAILED` are triggered on completion or failure. ### Identity Verification-Based Reset (SSPR) The self-service password reset (SSPR) feature lets users verify their identity using a valid identity document before resetting their password, no admin intervention needed. To enable it, turn on **Enable users to reset password through Identity Verification** under **Authentication > Reset Password > Reset Password Configurations**. #### How It Works The user clicks **Forgot Password**, enters their email, selects how they want to receive the verification link, and completes a document scan + selfie. Once identity is verified, they're taken directly to the password reset screen. {% hint style="warning" %} The password must be reset within **3 minutes** of identity verification. After that, the token expires and the process must be restarted. {% endhint %} #### Name Alias Matching Community Administrators can configure name aliases to handle common name variations during document matching, for example, mapping "Joe" to "Joseph" or "Mike" to "Michael". These are defined as a dictionary in the SSPR settings. #### Workday Integration If your organization uses Workday as the user attribute source, configure the following before enabling SSPR: * An Active Directory (AD) to 1Kosmos connection is required * Map Workday attributes to one of: `$employeeId`, `$username`, or `$email` * Write a transformation script to convert the Workday API response into 1Kosmos session attributes (first name, last name, DOB) * Enable the Workday option in SSPR settings; otherwise the system defaults to your preferred user store (e.g. AD) The Workday configuration screen accepts the API URL, authorization type (Basic Auth, Bearer Token, or No Auth), and a script editor where you can write and test your transformation logic before saving. {% hint style="info" %} Saving Workday configuration changes requires identity verification — you'll be prompted for a one-time code via email or SMS before changes are applied. {% endhint %} #### SSPR Event Logs The `E_IDV_DOCUMENT_VALIDATE` event is enhanced with fuzzy match scores and a session summary certificate. Both `E_PWDRESET_SUCCEEDED` and `E_PWDRESET_FAILED` include a `mode` field indicating how the reset was attempted: `email_link`, `email_link_with_otp`, `id_proofing`, `Authenticator`, or `Other`. For `id_proofing` mode, the session ID is also included. Common failure scenarios and their error messages: | Scenario | Error Message | | ------------------------------- | ------------------------------------------------------------- | | Generic password change failure | Generic error: Error while changing user password | | Password login not allowed | Your organization does not allow you to login with a password | | ID proofing not configured | DVCID not configured in SSPR settings | | ID proofing session expired | ID Proofing session is expired | | Document verification failed | Document verification failed | | User disabled or inactive | User is disabled / User is inactive | | Missing required attribute | employeeId / username / email is missing in the user object | | Transformation script failure | Transformation script failed | *** ### Enforcing Password History 1Kosmos supports password history enforcement during resets across all methods, mobile, AdminX, and identity verification. When enabled, users cannot reuse recently used passwords. Enable it via **Authentication > Reset Password > Password Reset Settings > Enforce Password History Check** in AdminX. {% hint style="info" %} **Prerequisites:** Go Broker service v1.09.02 or later, and password history must also be configured at the Active Directory level via Group Policy. {% endhint %} #### Configuring Password History in Active Directory In Group Policy Management, navigate to: **Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy** Set **Enforce password history** to the number of previous passwords to remember, and ensure **Minimum password age** is greater than 0. Run `gpupdate /force` to apply. When a user tries to reuse a previous password during reset, they'll see: # FIDO Keys FIDO passkeys enable passwordless login using biometrics or hardware security keys instead of passwords. *** ### Authenticator Types * **Security Keys** - Authenticators used to verify a user's identity. These can be **external hardware security keys** (USB, NFC, or Bluetooth) that authenticate using a touch, PIN, or biometric verification, or **platform-based security keys** stored on devices such as smartphones or computers (for example, passkeys on iPhone authenticated with Face ID or Touch ID). Security keys are also referred to as **roaming** or **platform authenticators**, depending on where they are stored. * **Platform Authenticators** - built into the user's device; authenticate using face recognition or fingerprint (e.g. Apple Touch ID/Face ID, Windows Hello, PIN) FIDO2/WebAuthn is supported on Chrome, Firefox, Edge, and Safari. {% hint style="warning" %} WebAuthn is not supported in incognito/private browsing windows. {% endhint %} ### Admin Configuration FIDO authentication is configured under **Authentication > FIDO** in AdminX. Toggle **Enable FIDO Login Using Security Keys & Platform Authenticators** on or off as needed. When enabled, expand the toggle to restrict authentication to a specific type - Security Keys only, Platform Authenticators only, or both. #### Managing Allowed Security Keys Every tenant comes pre-populated with the most commonly used security key models. Administrators can enable or disable individual models, add new ones, or update existing metadata. * **Enable/Disable a model** — toggle the switch next to any listed key and confirm with **Save** * **Add a new model** — click **Add New Key**, provide a name, upload the manufacturer's FIDO metadata file (`JSON` format), and set the enabled state * **Edit an existing model** — click the **pencil icon** to update the name or replace the metadata file {% hint style="warning" %} Disabling a key model immediately prevents users with that key from authenticating. {% endhint %} {% hint style="info" %} FIDO metadata files must be in `JSON` format. Contact your key manufacturer directly if you need the metadata file. {% endhint %} Click **Save Changes** at the bottom of the page after making any updates. *** ### User Device Enrollment Users enroll their FIDO devices from **My Profile** in AdminX. Both platform authenticators and security keys are registered from the **Setup** drop-down menu on that page. #### Registering a Platform Authenticator Go to **My Profile > Setup > Platform Authenticator**, click **Use Platform Authenticator**, grant browser permission when prompted, and give the device a unique name. The authenticator appears under the **Devices** tab once registered. #### Registering a Security Key (e.g. YubiKey) Go to **My Profile > Setup > Security Key**, click **Use Security Key**, insert the key into a USB port and tap it to verify presence, then assign a unique name. The key appears under the **Devices** tab once registered. ### Logging in with FIDO On the sign-in page, enter your username, select **Security Key** from the authentication method menu, then confirm with biometrics or a PIN (platform authenticator) or by tapping the device (security key). {% hint style="info" %} The Security Key option only appears if a FIDO authenticator is already registered to the account. {% endhint %} ### Removing an Authenticator Go to **My Profile**, locate the device under the **Devices** tab, click the **trash icon**, and confirm removal. #### Cross-Browser Usage A FIDO authenticator registered on one browser can be used on a different browser on the same device. {% hint style="info" %} Cross-browser authenticator use is not currently supported on Mac due to OS limitations. {% endhint %} # WebAuthn FIDO2 Web Authentication (WebAuthn) is a standard web API, built into modern web browsers and related web platform infrastructure, used to securely authenticate users across various sites and devices. *** ### Overview WebAuthn supports two authentication mechanisms, and 1Kosmos supports both: * **Platform authenticators** - Built into your hardware and often unlocked with biometrics (for example, Touch ID or Face ID). * **Roaming authenticators (security keys)** - External authentication devices, such as a YubiKey, that connect to your device via USB, NFC, or Bluetooth. Supported on Android and iOS. ### Supported browsers WebAuthn is currently supported in Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari. {% hint style="warning" %} **Incognito browsers:** WebAuthn is not supported in incognito/private browsing modes. {% endhint %} # LiveID (Biometric Authentication) LiveID is a 1Kosmos signature feature that enables workforce users to enroll their face once and authenticate on any supported device - desktop, mobile, or any camera-enabled device. *** ### Overview It is designed to replace traditional password-based login and passwordless methods that rely on biometric authenticator apps or passkeys. During enrollment, LiveID captures a high-quality, forward-facing selfie suitable for biometric verification. The system automatically checks face positioning, visibility, orientation, and pose stability before capturing. No manual interaction is required, the capture is fully automatic. ### Enrolling LiveID Users enroll their LiveID selfie from **My Profile** after logging in with any already-registered authentication method (for example, password + OTP or push notification). 1. Log in to your tenant 2. Navigate to **My Profile > Login Options** 3. Under the **Setup** drop-down, click **LiveID Selfie** 4. On the **Enroll LiveID Selfie** screen, review and accept the consent notice, then click **Capture**. 5. The camera opens and automatically captures your selfie 6. When prompted, enter a **4-digit PIN** and click **Submit** {% hint style="info" %} Note: **PIN is configurable (4/6/8)** {% endhint %} A confirmation message confirms successful enrollment. The PIN is required whenever an additional authentication factor is challenged, based on the configured authentication policy. ### Configuring Adaptive Authentication for LiveID Community Administrators configure LiveID as an authentication method via **Authentication > Adaptive Authentication**. Two options are available under the Decision Actions: | Method | Description | | ------------------------------------- | ---------------------------------------------------------------------------------- | | **LiveID Selfie** | Prompts the user to provide a selfie on a camera-enabled device | | **LiveID Selfie & Push Notification** | Uses facial biometric combined with push notification approval via the 1Kosmos app | ### Logging in with LiveID 1. Open the tenant URL 2. Navigate to the **LiveID Selfie** tab 3. Read the on-screen instructions, the camera opens automatically 4. Present your face; the system captures the selfie automatically once it detects a clear, stable image 5. Enter your **4-digit PIN** when prompted *(PIN length is configurable by the admin to contain 4, 6 or 8 digits)* 6. Upon successful authentication, you are logged into the tenant ### Best Practices * The image resolution should be at least **1080p** (1920×1080 px) * Use a well-lit environment to ensure clear image quality * Maintain a steady, forward-facing pose for at least 600ms * Keep your face within the on-screen circular frame * Avoid tilting your head left, right, or sideways * Avoid wearing headwear or face coverings that block facial features * Small, natural head movements are allowed and will not reset the capture * Follow the real-time guidance messages displayed during capture ### Troubleshoot This section explains what happens during a LiveID facial login, what errors and system events a user's failed attempt can generate, and what helpdesk staff should check or tell the user at each stage. **How LiveID Login Works** A login attempt moves through up to five stages, in order. If a stage fails, the process stops there, and the user sees an error. When a user contacts the helpdesk, the fastest way to diagnose the issue is to pull the most recent E\_LOGIN\_FAILED event for their session and check which stage it came from — the sections below tell you what each one means. {% stepper %} {% step %} #### **Stage 1: Selfie Capture** This stage never generates events, so if a user is stuck here, you're relying entirely on what they tell you or what's on their screen. There's no failure at this stage — only guidance messages while the app waits for a good image, and camera-access errors that block capture entirely. **Positioning guidance (normal, self-resolving)** These messages simply guide the user to reposition. They aren't errors — no action needed unless the user reports being stuck on one indefinitely (in which case, suspect a lighting or camera hardware issue). **Camera access errors (need helpdesk action)** Camera access is blocked. Enable camera permissions for this app, or contact your helpdesk if the issue persists {% endstep %} {% step %} #### **Stage 2: Security and Anti-Spoofing Check** Once the system captures an image, it checks it for signs of a spoofed or fraudulent attempt. A failure here always shows the same UI message, but the underlying event tells you why it was flagged. UI error shown to user: "**Suspicious Activity Detected**" Event generated: E\_LOGIN\_FAILED — check the event's recommendations field for the cause. {% endstep %} {% step %} #### **Stage 3: Liveness Check** If the anti-spoofing check passes, the system verifies the image shows a live person. Many of the causes below are the same conditions the Selfie Capture stage tries to prevent — so a failure here often means the user rushed through or ignored the on-screen guidance. UI error shown to user: "**Liveness check failed**" Event generated: E\_LOGIN\_FAILED — check the event's failureDetail field for the cause. {% endstep %} {% step %} #### **Stage 4: Face Compare** After liveness passes, the system tries to match the face to an enrolled identity. The error and recommended action depend on whether the user logged in with a username or without one. Event generated: E\_LOGIN\_FAILED — check the event's reason field. {% endstep %} {% step %} #### **Stage 5: User PIN Verification (Optional)** If PIN verification is enabled as a backup/secondary step, this is the last stage. Failure here simply means the entered PIN was wrong. UI error shown to user: "**Incorrect PIN**" **Event generated**: E\_LOGIN\_FAILED with reason: "Incorrect PIN" **What to do**: Confirm the user is entering the correct PIN. If they've forgotten it, direct them to your organization's PIN reset process. {% endstep %} {% endstepper %} **Quick Reference: Diagnosing from the Event Log** When a user reports a failed login, pull their E\_LOGIN\_FAILED event and check which data field is populated — it tells you which stage failed: If there's no E\_LOGIN\_FAILED event at all, the user likely never got past Stage 1 (Selfie Capture/camera access) — ask them what was on screen when the attempt stopped. **Stage-by-stage summary** The table below summarizes what each stage does and whether it leaves an event trail to check.
# Stage What it does Generates events?
1 Selfie Capture Guides the user to position their face for the camera No
2 Security & Anti-Spoofing Check Screens the image for signs of spoofing (fake video, virtual camera, etc.) Yes
3 Liveness Check Confirms the image is a real, live person Yes
4 Face Compare Matches the face to an enrolled user Yes
5 User PIN Verification (optional) Validates a backup PIN, if enabled Yes
**Positioning guidance messages** These are the on-screen prompts users see while the app waits for a good image. | Message shown to user | What it means | | -------------------------------- | -------------------------------------------- | | "Loading face detector..." | App is initializing | | "Move closer" | Face is too small/far from camera | | "Move back a little" | Face is too close to camera | | "Center your face in the circle" | Face is outside the focus area | | "Keep your head level" | User is facing the camera but head is tilted | | "Face the camera directly" | User isn't facing the camera | | "Please hold the position" | All conditions met — about to capture | **Camera access errors** If capture never starts, one of these messages is likely on screen — check the cause and share the fix with the user. | Message shown to user | Likely cause | What to tell the user | | ------------------------------------------------ | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | "Camera permission denied" | Browser/app camera permission was denied | Have them enable camera access in browser/OS privacy settings, then reload | | "No camera found" | Device has no camera, or it's disabled/disconnected | Confirm the device has a working camera; check Device Manager (Windows) or System Settings for a disabled camera | | "Camera is already in use" | Another app (Zoom, Teams, etc.) is holding the camera | Ask the user to close other apps using the camera, then retry | | "Camera access blocked (try non-incognito mode)" | Browser is blocking camera access, often due to incognito/private mode | Ask the user to retry in a normal (non-private) browser window | **Anti-spoofing failure causes** Check the event's recommendations field against this table to identify why the attempt was flagged. | Cause (in event data) | What it means | What to do | | ------------------------ | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Unknown exception | An unexpected internal error occurred during detection | No specific user action — treat as a system-side issue; escalate if it recurs | | Virtual camera detected | The video source looks like a virtual camera or screen-capture feed rather than a physical camera | Ask the user to check that their physical webcam (not a virtual/software camera) is selected as the video source | | Video injection detected | The video stream looks synthetic or pre-recorded rather than live | Ask the user whether they are replaying a recorded video instead of using a live camera feed | | Video anomalies | The video shows unusual patterns or is unusually static/flat | Suggest the user retry with better lighting and normal camera movement; escalate for manual review if it persists | **Liveness check failure details** Match the event's failureDetail value to this table for the likely cause and recommended action. | failureDetail value | What it means | Recommended action | | --------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | "Face not found" | No face detected in the image | Ask the user to retry, ensuring their face is clearly visible | | "Relative face size is too small" | Face is too far from the camera | Ask the user to move closer | | "Facial out-of-plane rotation angle is extremely large" | Head was tilted too far | Ask the user to keep their head level and face the camera directly | | "Absolute face size is too small" | Camera resolution/face pixel density too low | Ask the user to move closer and ensure good lighting | | "Face is too close to one or more borders" | Face was too near the edge of the frame | Ask the user to center their face in the capture area | | "Face is cropped" | Only part of the face was captured | Ask the user to retry, keeping their full face in frame | | "Face is occluded" | Something is covering part of the face (mask, hand, hair, etc.) | Ask the user to remove anything covering their face and retry | | "Too many faces detected" | More than one face appeared in frame | Ask the user to try authenticating in a less crowded location | | "Image too small to be processed" | Captured image is below 480p resolution | Check the user's camera meets minimum resolution requirements | | "Liveness score below configured success threshold" | Liveness confidence was too low (image queued for Stage 2 manual review) | No immediate user action — inform them the attempt is under review | | "Poor image quality. Retry login." | Image quality was too low (image queued for Stage 2 manual review) | Ask the user to retry in a well-lit location | | "Both liveness and quality score below success threshold" | Both checks failed (image queued for Stage 2 manual review) | Possible spoofing — check whether the user tried to present a recorded video via smartphone | **Face Compare failure scenarios** | Login Flow | Condition | UI Message | Event Reason Failure | What to do | | ---------------- | ---------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Without username | Face isn't enrolled at all | "No account found" / "Face Not Recognized" | "No account found" / "Face Not Recognized" | Confirm the user has completed facial enrollment; if not, direct them to enroll | | Without username | Face matched an image, but that image isn't linked to any user account | "Your selfie has not been enrolled" | "User not found" | Confirm the user's enrollment is fully linked to their account; may need re-enrollment | | With username | Captured face doesn't match the enrolled face for that username | "Face does not match" | "Selfie does not match the selected user" | Confirm the user is entering the correct username; if repeated, check whether their enrolled photo is outdated (e.g., major appearance change) and may need re-enrollment | **Diagnosing from the Event Log** | Event field present | Stage that failed | Go to section | | ------------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------------- | | recommendations | Security & Anti-Spoofing Check | [Stage 2](#stage-2-security-and-anti-spoofing-check) | | failureDetail | Liveness Check | [Stage 3](#stage-3-liveness-check) | | reason ("No account found," "User not found," or "Selfie does not match the selected user") | Face Compare | [Stage 4](#stage-4-face-compare) | | reason ("Incorrect PIN") | User PIN Verification | [Stage 5](#stage-5-user-pin-verification-optional) | #### Enrollment Failure Reasons With the new **E\_LIVEID\_ENROLL\_FAILED** event, triggered on a LiveID Selfie enrollment failure, the table below breaks down each failure reason and the details it captures. | Failure Reason | Details Captured | | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Liveness failed (when liveness score is part of registration scope) | Liveness score, quality score, reason for low liveness/quality score | | Suspicious activity detected | Overall confidence score, camera name, reason for high-risk confidence (e.g. virtual camera, synthetic video, flagged camera name) | | Incorrect PIN (when a PIN already exists) | Failure reason: PIN mismatch | # Behavioral Authentication Behavioral Authentication in 1Kosmos analyzes how a user interacts with their device, specifically their typing pattern, and compares it against their enrolled behavioral profile to verify identity. *** ### Overview **Behavioral Authentication** is particularly useful in environments requiring complex passwords (14–16 characters for PCI DSS compliance). With Behavioral Authentication and a PIN enrolled, users can log in without repeatedly typing long passwords. It is also ideal for workplaces where cameras are unavailable for LiveID Selfie authentication or where users cannot carry personal devices to use authentication methods such as QR codes, Push notifications, TOTP, or Security Keys. For more information see [Behavior Authentication](/authentication/windows-workstation-mfa/authentication-methods/behavior-authentication). # Orion Desktop Authenticator Orion Authenticator is a desktop application that delivers strong, passwordless authentication and TOTP-based MFA directly from a user's Mac or Windows workstation — without requiring a mobile device. For more information see [Orion authenticator.](/authentication/orion-desktop-authenticator/overview) # Hardware Tokens HMAC-based One-Time Password (HOTP) tokens are hardware devices that generate single-use passcodes based on a shared secret and an incrementing counter. *** ### Overview Unlike TOTP, HOTP codes are not time-bound - they remain valid until the next code is generated, making them well-suited for offline environments or systems where clock synchronization is unreliable. *** ### Enabling Hardware Tokens Before using hardware tokens, enable them under **Authentication > Multi-Factor Authentication > Login with One-Time Codes**: * Check **Use passcodes from hardware tokens** * Enter a domain and URL in the Token Configuration section The Hardware Tokens dashboard is accessible from **Authentication > Hardware Tokens**. *** ### Managing Tokens Community Administrators with the appropriate permissions can provision, assign, modify, and export tokens from the Hardware Tokens dashboard. {% hint style="info" %} All update actions require the **authentication.hardware-tokens.view** permission plus at least one of: `create`, `update`, or `delete`. {% endhint %} #### Provisioning Tokens Tokens are imported via CSV. Click **Import Tokens** on the dashboard, then upload a file or paste token data directly in this format: ``` ,, ``` The counter field is optional - if omitted, it defaults to 0. Imported tokens start with an **inactive** status and become active on first use. **CSV rules:** * Maximum 25,000 records per upload; file size must not exceed 25MB * Counter must be a non-negative integer (no decimals, negatives, or special characters) * No blank rows between records #### Assigning Tokens to Users Click a token's serial number to open its details, then click **Add User** and enter a username. A single token can be assigned to multiple users, and a single user can hold multiple tokens. #### Removing a User from a Token Open the token details, locate the user under the **Users** section, click the **Delete** icon, and confirm with **Delete User**. #### Viewing Tokens and Users The dashboard has two tabs: * **Tokens** — lists all provisioned tokens with status, assigned user count, and edit/delete options * **Users** — lists users who have tokens assigned, with last active date and the option to remove a user from all tokens #### Modifying a Token Click **Edit** next to a token to update its counter or seed value. Click **Update Token** to save. {% hint style="info" %} The current seed value cannot be read — only replaced. {% endhint %} #### Resynchronizing Tokens Tokens can fall out of sync when the hardware counter is ahead of the server's counter. The server can correct drift of up to **50 counter steps**. If drift exceeds this, manually reset the counter in AdminX before retrying. To resync, click **Edit** on the token, click **Re-sync Token**, generate three sequential passcodes from the device, enter them in the Re-sync Token window, and click **Update**. #### First-Time Token Sync For tokens that have never been used, 1Kosmos prompts users to complete a one-time sync during their first login. On the **Enter your verification code** screen, the user clicks **First login with token? Continue to sync token**, enters three consecutive passcodes, and clicks **Sync Token & Login**. Configure the sync window range (1–500,000) under **Authentication > Multi-Factor Authentication > Hardware Token Sync Window**. {% hint style="info" %} If multiple tokens are assigned to the user, a dropdown lets them select which token to sync. If the token has already been synced, users can click **Already Synced? Continue to Login** instead. {% endhint %} **Event Logs** — `E_TOKEN_MODIFIED` (activity: authentication) and `E_OTP_VERIFIED` (contains hash of the third OTP) share the same `requestId` during a sync. #### Authenticating with a Hardware Token On the login screen, select **Password & OTP**, enter the password, then select **Hardware Token**, generate a passcode from the device, and enter it. #### Exporting Token Data Click **Export Data** on either the **Tokens** or **Users** tab, enter an email address, and click **Generate**. The report is delivered by email when ready. *** ### Event Logs The following events are triggered by hardware token activity: * `E_OTP_VERIFIED` * `E_LOGIN_SUCCEEDED` * `E_LOGIN_FAILED` * `E_TOKEN_LIST_EXPORTED` * `E_TOKEN_ASSIGNMENT_EXPORTED` * `E_TOKEN_ADDED` * `E_TOKEN_MODIFIED` * `E_TOKEN_ASSIGNED` * `E_TOKEN_UNASSIGNED` * `E_TOKEN_DELETED` # Adaptive Authentication Adaptive Authentication verifies the user's identity based on factors such as location, device status, and end-user context. *** ### What you can do with it Adaptive Authentication offers several business scenarios that enhance security and user experience: * **Deny access** — block access for specific users or groups when they match predefined conditions, such as IP address range, group membership, or application access. * **Request specific authentication factors** — require additional factors such as one-time passwords (OTP), push notifications, or biometric authentication for higher-risk applications, sensitive transactions, or both. * **Different rules for inside and outside networks** — apply separate authentication policies for internal versus external network access. For example, stricter requirements can be enforced for external access to ensure security compliance. * **Grant access** — bypass authentication for specific applications when users are within a designated network range, avoiding redundant authentication (for example, when users would otherwise be prompted again while already inside the same network). When access has been bypassed for an application, users log in directly using username or QR code without being asked for additional authentication factors. ### Configure it Adaptive Authentication is set up in the Admin Portal, where administrators create journeys by defining conditions and decision actions. For prerequisites and step-by-step configuration, see [Configure Adaptive Authentication.](/authentication/admin-portal/authentication/configure-adaptive-authentication) # Multi-Factor Authentication Multi-factor Authentication (MFA) requires users to verify their identity using two or more factors before gaining access. *** ### Overview 1Kosmos supports a range of second-factor methods, giving administrators the flexibility to enforce the right level of security for their users and applications. ### Available Authentication Methods | Method | How it works | | ---------------------- | ------------------------------------------------------------------ | | **OTP via Email** | A one-time passcode is sent to the user registered email address | | **OTP via SMS** | A one-time passcode is sent to the user registered mobile number | | **OTP via Voice Call** | A one-time passcode is delivered via a voice call | | **Hardware Token OTP** | User generates a passcode from a linked hardware token | | **Push Notification** | A push notification is sent to the 1Kosmos mobile app for approval | | **QR Code** | User scans a QR code using the 1Kosmos mobile app | All methods can be used standalone or in combination with a password as a second factor. How to setup on AdminX, visit [setup multi factor authentication](/authentication/admin-portal/authentication/setup-multi-factor-authentication) # Use cases *** Use cases show how 1Kosmos passwordless authentication is applied to real-world deployment scenarios. Each one walks through the setup and user experience for a specific environment or workflow, so you can adapt the closest match to your own rollout. Explore the available use cases: * **Entra Passkey for Frontline Workers** — Passwordless access for shared-device, frontline environments using Entra-backed passkeys. * **In-Flight Enrollment for EAM (Behavior Auth + PIN)** — Let pre-authenticated EAM users enroll Typing Pattern and a PIN during login, with no personal device required. # Entra Passkey for Frontline Workers 1Kosmos enables frontline workers to authenticate into Microsoft Entra using a passkey verified through LiveID biometric (selfie). *** ### Overview Identity is confirmed in real time - ensuring only the verified individual gains access, not just a trusted device or credential.
### What it is This use case lets frontline workers sign in to Microsoft Entra using a passkey that is verified with a LiveID biometric selfie, rather than a password alone. Because authentication is tied to a live facial biometric, access is confirmed in real time for the verified individual - not just for a trusted device or credential. ### How it works This integration supports two delivery channels depending on your deployment scenario: * **Mobile** — for field workers on Intune-managed iOS devices * **Browser** — for desk-based workers using Chrome Both channels use the same underlying PassKey + LiveID authentication workflow. Before configuring either channel, ensure the following are in place. ### Prerequisites * A 1Kosmos tenant with a community configured * Users provisioned in Microsoft Azure AD * LiveID enrolled and passkey registered for each user via the Registration workflow * Access to AdminX * Authentication workflow (`PassKeyWithLiveID`) deployed and active, with a valid access code --- [Next Page](https://docs.1kosmos.com/llms-full.txt/1)