A reported exposure puts ID scanning practices under scrutiny
A newly reported cybercrime service called Nexus claimed to offer digital scans of more than 153 million driver’s licenses belonging primarily to people in the United States and Canada. According to an investigation published by cybersecurity journalist Brian Krebs on September 1, 2026, the service also claimed to contain millions of other identity records, including identification cards, travel documents, international IDs, and medical cards.
Krebs reported that the FBI’s New Orleans field office opened an inquiry into the apparent breach. His reporting linked some records to occasions when individuals had presented their licenses at businesses such as a rental car counter or a dispensary. He identified Louisiana based identity verification provider IDScan.net as the apparent focus of the inquiry. IDScan told Krebs that it was investigating but had not issued a substantive public explanation when his story was published.
These details remain allegations under investigation. The reported record totals are claims made by the Nexus service and have not been independently confirmed by a regulator or law enforcement agency. Still, the evidence described by Krebs presents a serious warning for every business that scans and retains identity documents, including hotels.
What IDScan had to do with the reported exposure
IDScan and Nexus were not the same operation. IDScan is a legitimate company that supplies identity verification hardware and software to businesses. Nexus was the criminal service that reportedly advertised access to stolen identity records. The allegation is that Nexus may have obtained records processed by IDScan’s systems.
As of September 6, 2026, that connection remains strongly suspected but not officially proven. Reuters reported that it could not independently establish the source of the records. The FBI confirmed that it was looking into the incident but declined to provide further information because the investigation was ongoing. IDScan acknowledged an internal investigation to Krebs but had not publicly confirmed that its systems were compromised, how an intrusion may have occurred, which customers were involved, or how many people were affected.
Why investigators focused on IDScan
The connection did not come from the Nexus operators merely naming a company. Krebs and security researcher Zach Edwards worked backward from the records and the circumstances in which the IDs had been presented.
First, Krebs searched the Nexus database for his own license and, with permission, the licenses of more than a dozen friends and relatives. He reported finding nine of those individuals. The timestamps attached to their images corresponded to dates on which they had traveled or rented vehicles.
Second, Krebs and his mother reportedly handed their licenses to the same Hertz representative during a June 2025 rental transaction. Images of both licenses appeared in Nexus with timestamps only seconds apart. Other individuals also matched timestamps on their records to Hertz rentals.
Third, Edwards found his license in Nexus with a timestamp from a visit to Las Vegas. He had presented the license at several places, but the business that he knew had scanned it was Planet 13. IDScan had publicly described Planet 13 as a customer using its identity authentication technology.
Fourth, some Nexus records reportedly contained visible light, ultraviolet, and infrared images of the front and back of an ID. IDScan’s own materials describe identity authentication using ultraviolet and infrared examination. That similarity does not prove where the files originated, but it is another reason the company became the focus of the reporting.
Finally, Nexus claimed that its records came from an active compromise of a major identity verification provider and that new information had been taken for more than a year. Krebs observed the advertised driver’s license count rise by almost 400,000 records in about 24 hours. Those statements and totals came from criminals and should not be treated as independently verified facts.
What IDScan’s published retention settings show
IDScan’s own support documentation provides important context about what its VeriScan platform is capable of collecting and retaining. According to the company’s current support page, administrators on eligible plans can choose not to collect personal data, collect anonymized data, collect all available data, or select particular fields.
The same documentation says that “images” can include a cropped ID photograph and a live webcam photograph. “Attachments” can include high resolution images of the front and back of an ID, along with agreements or reports associated with the history record.
The support page also states that new accounts default to collecting all data and retaining all records in the cloud. It says the Basic plan is set to collect all and not delete the records, and those settings cannot be changed on that plan. Premium, Enterprise, and ID Authentication plans provide additional collection or deletion options. For Classic VeriScan on Windows, the company says local database settings must be configured separately from cloud settings.
These published defaults do not prove that the Nexus records came from VeriScan, that every customer used those defaults, or that any particular hotel’s data was involved. They do demonstrate why configuration matters. A platform may offer data minimization and automatic deletion while still retaining considerably more information when an administrator does not select those controls or when a plan does not make them available.
IDScan also maintains a Trust Center and describes VeriScan as a privacy focused platform with configurable retention. Those representations should be considered alongside, not replaced by, the ongoing investigation. Compliance materials and configurable security features are useful, but hotels must confirm how their own account is actually configured and whether local databases, cloud records, images, attachments, exports, and backups follow the intended retention policy.
What has happened since the original report
The Nexus website disappeared shortly after Krebs published his findings. Its disappearance does not establish that copies of the information were destroyed or recovered.
On September 4, BleepingComputer reported that multiple lawsuits had been filed against IDScan in Louisiana and that law firms were investigating potential class actions. The publication also reported that some business customers may have begun receiving notifications around September 1. Lawsuits contain allegations, not factual findings, and the existence of litigation does not establish that IDScan caused the exposure.
BleepingComputer reported that IDScan had not issued a public statement or responded to its questions. Reuters similarly said IDScan did not respond to repeated requests for comment. Until IDScan, law enforcement, a regulator, or an independent forensic investigation releases more information, it would be inaccurate to describe IDScan as the confirmed source of 153 million exposed licenses.
The most accurate description is that IDScan is the suspected identity verification provider connected to the records and the apparent focus of the investigation.
Why this matters to hotels
Hotels routinely ask guests to present government issued identification at check in. That process can help confirm a reservation, reduce fraud, support age verification, and document a guest interaction. It can also create a valuable target if complete ID images and related personal information are collected without strict controls.
A driver’s license can contain a guest’s legal name, home address, date of birth, photograph, physical characteristics, document number, signature, and machine readable barcode data. Some advanced scanners may also create visible, ultraviolet, or infrared images. When those files are retained together, the result is far more sensitive than a simple confirmation that the person at the desk presented a valid ID.
For hotels, the central lesson is straightforward: scanning an ID is not only a front desk workflow. It is a data governance decision.
Every property should be able to answer four questions:
- What guest information is being collected?
- Where is that information stored and transmitted?
- Who can view, download, or export it?
- When is it deleted?
If management cannot answer those questions, the property does not have enough visibility into its own risk.
Who controls the scanned ID after check in?
Data ownership and data control should never be left to an assumption or a verbal sales promise. Before a hotel scans its first guest ID, its agreement with the provider should clearly state who acts as the business or data controller, who acts as the service provider or processor, what rights each party has, and whether the hotel can retrieve and permanently delete the records.
A hotel recently told Guest Ban that it was using TokenWorks and asked for its stored ID records to be deleted. According to the hotel’s account, that request was denied and the hotel was told that TokenWorks owned the scanned ID data and that the hotel did not have the right to require deletion.
Guest Ban has not independently reviewed the complete correspondence, account configuration, or contract involved in that dispute, so this account should not be presented as a verified statement of TokenWorks policy. TokenWorks should have an opportunity to explain what occurred and whether a legal hold, backup rule, product limitation, or contractual provision applied.
The account is nevertheless concerning because it illustrates the operational problem created when a hotel discovers only after collecting guest IDs that its understanding of control or deletion rights differs from the provider’s interpretation.
TokenWorks’ currently published legal documents appear to describe a different relationship from the one reported by the hotel. Its Data Processing Addendum states that TokenWorks acts as a processor or service provider when processing personal data for a customer, while the customer acts as the controller or as a processor for another party. The same document says that, upon a customer’s request or termination, TokenWorks will return or securely delete personal data and existing copies unless applicable law requires retention.
Its IDVisor Product Addendum adds qualifications that hotels should examine carefully. It gives a customer 30 days after termination to export customer data, permits TokenWorks to retain information in backup, archival, and disaster recovery systems for an additional period, and allows certain uses of customer data to develop, train, improve, and enhance services, subject to applicable law and the Data Processing Addendum. The Data Processing Addendum also allows the use of properly deidentified or aggregated information under stated conditions.
Those provisions do not establish what happened in the individual hotel’s case. They do show why the word “ownership” by itself is not enough. A hotel may be described as the controller while the provider still possesses copies, uses subprocessors, maintains backups, or reserves defined processing rights. Conversely, a provider’s disclaimer of ownership does not necessarily mean it has no security, deletion, or notification responsibilities.
Hotels should request written answers to five questions before signing an agreement:
- Does the hotel control the scanned record and have the right to retrieve it?
- Can the hotel require deletion at any time, rather than only after termination?
- Does deletion cover production systems, local devices, cloud storage, exports, and backups?
- May the provider use identifiable or deidentified guest data for analytics, product development, or artificial intelligence training?
- Which service providers or subprocessors receive the information, in which countries, and for what purposes?
If the sales explanation, privacy policy, product addendum, and Data Processing Addendum do not say the same thing, the hotel should resolve the conflict in writing before allowing the system to collect guest IDs.
A working scanner is not the same as a secure system
Hotels often evaluate an ID scanning product by speed, accuracy, and compatibility with the property management system. Those factors matter, but they are only part of the evaluation.
Security should cover the entire information lifecycle, from the moment a guest hands over an ID through capture, transmission, storage, use, access, export, backup, and final deletion. A system can scan accurately and still expose a hotel if it retains unnecessary images, gives too many employees access, relies on weak authentication, or sends sensitive records through insecure channels.
The Federal Trade Commission advises businesses to inventory the personal information they hold, keep only what they need, protect it, dispose of it securely, and prepare an incident response plan. The FTC also recommends investigating service providers’ security practices, putting security expectations into contracts, verifying compliance, and requiring vendors to report security incidents.
Those recommendations are especially relevant for hotel operators because guest information can pass through several systems and companies. The hotel may collect the ID, but a scanner vendor, cloud platform, support provider, property management system, or integration partner may process or store some part of the record.
Eight questions hotels should ask every ID scanning vendor
Before deploying or renewing an ID scanning system, hotel owners and operators should request clear answers to the following questions.
1. Who controls the record and the decision to delete it?
The contract should identify the hotel’s rights and the vendor’s role. Ask whether the hotel can export and delete records during the contract, what exceptions apply, how quickly deletion occurs, and whether the vendor will provide written confirmation. “Customer data” should be precisely defined to include images, extracted fields, barcode contents, biometrics, attachments, audit records, and derived data.
2. Does the system store a complete image of the ID?
Ask whether the platform retains the front image, back image, barcode data, ultraviolet image, infrared image, guest photograph, or extracted text. Determine which elements are required for the hotel’s business purpose and which can be avoided.
3. How long is each record retained?
Retention should be intentional, documented, and tied to a legitimate operational, contractual, insurance, chargeback, or legal need. Keeping every record indefinitely simply because storage is inexpensive increases the amount of information that could be exposed.
4. Can the hotel configure retention?
A property should understand whether retention can be selected by account, record type, or operational purpose. It should also know what happens to backups and replicated data after a record is deleted.
5. Who can access guest records?
The vendor should support individual user accounts, role based permissions, prompt removal of former employees, and audit records showing access and important actions. Shared front desk passwords make accountability much harder.
6. How is information protected?
Ask about encryption during transmission and storage, multifactor authentication, security monitoring, vulnerability management, independent assessments, and restrictions on vendor personnel. Marketing phrases are not enough. Request current documentation that explains the controls in practical terms.
7. What happens when a security incident occurs?
The contract should define how quickly the vendor must notify the hotel, what information the notice must contain, who leads the investigation, how evidence is preserved, and how affected properties and guests will be supported.
8. Can the vendor demonstrate deletion and accountability?
Hotels should ask how deletion is verified, whether records remain in exports or backups, whether subcontractors receive the data, and how the vendor records access, changes, and administrative activity.
Practical steps hotel operators can take now
This reported incident is an opportunity to review the property’s current process before a problem occurs.
First, create a simple data map. Identify every location where guest IDs or extracted details may exist, including scanner workstations, local folders, email inboxes, shared drives, cloud portals, backups, and the PMS.
Second, remove unnecessary copies. Front desk employees should not save ID images to desktops, personal folders, messaging apps, or unapproved cloud storage. If a record must be retained, it should remain in the approved system with access controls and an audit trail.
Third, review user access. Disable former employees, replace shared accounts with individual credentials, require multifactor authentication where available, and limit exports to authorized managers.
Fourth, document retention. The hotel should decide why each type of record is kept, how long it is needed, and how it will be securely deleted. Management should review that schedule with qualified legal counsel because requirements can vary by location, contract, and purpose.
Fifth, test deletion before a dispute arises. Select test records, submit a deletion request, and require the provider to explain what was removed, what remains in backups, when those remaining copies will expire, and whether any subprocessors retain a copy.
Sixth, prepare for an incident. Keep current contact information for vendors, cyber insurance, legal counsel, and technical support. Establish who has authority to disconnect a system, preserve evidence, contact affected partners, and make notification decisions.
How Guest Ban fits into a responsible hotel ID workflow
Guest Ban is designed to help hotels capture guest information, transfer authorized details into supported property management systems, maintain records for defined operational needs, document incidents, and manage Do Not Rent decisions from a controlled platform.
Guest Ban does not sell guest ID data. It does not provide scanned IDs or guest identity information to unrelated third parties for advertising, data brokerage, marketing, or the third party’s independent commercial use. When a hotel directs Guest Ban to transfer authorized guest details to its property management system, that transfer is performed for the hotel’s requested check in workflow. Service providers that are necessary to operate and secure the platform may process limited information under contractual confidentiality and data protection requirements, but they are not permitted to treat the hotel’s guest records as their own product.
Guest Ban does not claim ownership of a guest’s identity or use an ownership claim to prevent a hotel from controlling its authorized records. The hotel remains in control of the records collected for its operations and can request deletion in accordance with applicable law, the service agreement, documented retention requirements, and necessary backup expiration processes.
That distinction matters. A simple promise that information is “not sold” does not answer whether a provider sends it to other companies, uses it to train models, keeps it after the hotel requests deletion, or claims independent rights over it. Hotels deserve direct answers to each of those questions.
Technology alone, however, does not create a complete privacy program. Each hotel should configure access and retention according to its actual needs, train staff to use the approved workflow, promptly remove users who no longer require access, and avoid creating additional copies of guest IDs outside the system.
When evaluating Guest Ban or any identity solution, the right conversation should include both operational value and information stewardship. Faster check in and better documentation matter. So do data minimization, hotel control, enforceable deletion rights, restricted disclosure, an appropriate retention schedule, vendor accountability, and a clear incident response plan.
The takeaway
The reported Nexus database shows how attractive identity documents can be to criminals and how one service provider may become a concentrated point of risk for many businesses and their customers.
Hotels do not need to stop verifying identity. They do need to treat every scan as sensitive information from the moment it is captured. Collect only what serves a defined purpose, keep it only as long as necessary, restrict access, verify vendor protections, and plan for the possibility of an incident.
Guest trust begins at the front desk. Protecting the information handed across that desk is part of protecting the guest.
Sources and editorial note
The description of Nexus, its claimed record counts, the timestamp analysis, the reported FBI inquiry, and the apparent connection to IDScan are based principally on Brian Krebs’s September 1, 2026 report, FBI Probes Service Selling 153M+ Drivers Licenses. The original report states that the matter was developing and that IDScan was investigating. The source article supplied for this assignment was Tom’s Hardware coverage published September 2, 2026.
Reuters independently confirmed the FBI’s acknowledgment of an investigation but stated that it could not establish the source of the stolen records. TechCrunch reported the suspected IDScan connection and the company’s initial response. BleepingComputer reported the subsequent lawsuits and continuing lack of public confirmation.
The discussion of collection and retention options is based on IDScan’s own support documentation, How can I control what visitor data is collected and retained?, and the company’s Trust Center. Product settings may change, and individual customer configurations may differ.
