Connectivity changes the procurement question
A connected arcade machine may exchange status, configuration, diagnostic, payment, player, or operational data with readers, local servers, cloud services, and third parties. Connectivity can support useful workflows, but this article is not an argument about IoT operating benefits or a comparison of payment platforms. It addresses a narrower purchasing issue: how to determine who controls the system, who can access the data, how security is maintained, and what happens when the commercial relationship ends.
Many buyers evaluate cybersecurity too late. Hardware is selected, the venue network is nearly complete, and only then does an IT team ask about ports, credentials, logs, updates, and data flows. By that stage, contractual leverage is limited and architectural changes are expensive. Cybersecurity and data ownership should instead appear in the request for proposal, security schedule, acceptance test, and exit plan.
NIST Special Publication 800-213 frames IoT acquisition around defining device cybersecurity requirements that support the acquiring organization’s own risk management. That principle is directly useful for arcades: do not buy a vague promise that a device is “secure.” Identify the capabilities, information, documentation, and lifecycle support your organization needs, then obtain evidence for the quoted configuration.
NIST SP 1800-36 demonstrates trusted-network-layer approaches for onboarding and managing IoT devices. It reinforces that device identity, network authorization, inventory, monitoring, and segmentation are architectural concerns—not settings to improvise after installation. Neither publication certifies an arcade product, and this guide does not claim that a Sunflower machine conforms to them. Buyers can use the publications as structured references when requesting model-specific information.
Map every component and data flow
Start with a system diagram. A “machine” can contain a game computer, embedded controller, cashless reader, payment terminal, operator interface, Wi-Fi or cellular module, switch, remote support agent, and third-party software. Each component may have a different manufacturer, administrator, update process, and data destination.
Require a logical and physical architecture diagram showing:
- all network-capable components and their interfaces;
- wired, wireless, Bluetooth, cellular, USB, and service ports;
- local servers, gateways, cloud endpoints, and third-party processors;
- protocols, destination domains or addresses, and required inbound/outbound connections;
- trust boundaries and encryption points;
- administrative, service, operator, and player interfaces;
- what happens when connectivity is lost;
- data stored locally, transmitted remotely, or exported;
- time synchronization and log destinations.
Then build a data-flow inventory. For each data element, record the source, purpose, legal basis where relevant, destination, retention period, controller/owner, processor, permitted users, export format, deletion method, and whether it can identify or be linked to a person. Do not let “telemetry” remain an undefined category. Diagnostic logs may include device identifiers, IP addresses, timestamps, staff usernames, location, or transaction references.
From a buyer perspective, the absence of a diagram is itself information. It may mean that responsibilities across the game manufacturer, cashless provider, integrator, and operator have not been reconciled. The contract should not rely on one vendor’s assumptions about another vendor’s system.
Define data ownership as usable rights
A sentence stating “the customer owns its data” is not enough. Ownership without access, documentation, or export rights may have little operational value. Define rights by data category and lifecycle.
Ask these questions:
- Which party controls raw machine events, aggregated analytics, account information, payment-related records, player identifiers, support logs, and derived insights?
- Can the supplier use customer data to improve products, benchmark venues, train models, market services, or create anonymized datasets?
- What de-identification method is used, and can data be re-linked through location or device identifiers?
- Can the buyer export all relevant records at any time without a professional-services fee?
- What formats, schemas, field definitions, time zones, units, and identifiers are provided?
- Are API access, bulk export, and historical depth included in the price?
- How quickly are deletion and return completed after termination?
- What backups retain deleted data, for how long, and under what access controls?
- What happens to data if the service provider is acquired, becomes insolvent, or discontinues the product?
- Which subcontractors or sub-processors receive the data, and how are changes disclosed?
Put answers in the order form and data-processing terms. Include a precedence clause so a marketing page cannot override negotiated rights. Require reasonable assistance for legal, privacy, and incident-response obligations in the destination jurisdiction.
Buyers should also separate possession from control. A local copy does not help if the platform keeps the only intelligible schema. Conversely, an API is not a complete exit solution if it is rate-limited, excludes historical data, or ceases immediately on notice of termination.
Specify API and integration requirements before signing
An API commitment should identify supported use cases and service boundaries. Ask for current documentation under confidentiality if necessary, then test with realistic records.
The procurement checklist should cover:
- authentication method and credential rotation;
- authorization granularity and tenant isolation;
- documented endpoints, field definitions, and versioning;
- pagination, rate limits, quotas, and expected latency;
- filtering by venue, machine, event type, and time;
- webhook security, retries, ordering, and duplicate handling;
- error codes and support escalation;
- development or sandbox environment;
- audit logging of API access;
- backward-compatibility period and deprecation notice;
- bulk historical export independent of the API;
- time-zone and clock synchronization rules;
- costs for access, volume, connectors, and future versions.
The contract should state what happens when an API changes. “Best efforts” may not protect a distributor supporting many venues. Require notice, migration documentation, a testing window, and a defined period in which the prior version remains available, tailored to business risk.
A Sunflower design engineer would typically need to understand interface boundaries, supported protocols, electrical integration, software dependencies, and responsibility for third-party readers before confirming a machine configuration. Buyers may request exact interface and compatibility information for a shortlisted model, rather than assuming every option works with every cashless or IoT service.
Accounts, roles, and privileged access
Shared administrator accounts weaken attribution and make offboarding difficult. Require named accounts where practical, role-based access, least privilege, and a clear inventory of privileged roles. Define roles for corporate IT, venue manager, floor technician, cashier, distributor service, manufacturer support, and read-only audit.
Ask whether the system supports multifactor authentication, single sign-on, enforced password controls, session timeout, device approval, IP restrictions, and emergency access. If a feature is unavailable, document compensating controls and risk acceptance. Require immediate credential revocation when staff or service partners change.
Remote support deserves particular scrutiny. Establish whether access is always on or approved per session, who can initiate it, whether the operator sees an indicator, how sessions are authenticated, whether file transfer is permitted, and how activity is recorded. Generic remote desktop tools, default credentials, hidden maintenance accounts, or shared vendor passwords should trigger remediation before acceptance.
The buyer should receive a list of all default, service, and recovery credentials and a controlled commissioning process to replace them. The supplier should disclose any account that the buyer cannot disable and explain why it is necessary. Recovery procedures must avoid locking the venue permanently to one individual’s phone or email address.
Logging, monitoring, and evidence preservation
Logs serve security, troubleshooting, compliance, and dispute resolution. Request a logging matrix showing event types, timestamp source, retention, storage location, access permissions, integrity protections, and export method.
Useful events may include successful and failed logins, privilege changes, configuration changes, firmware updates, remote sessions, device onboarding, network changes, API access, export activity, security alerts, and system restarts. Payment-related logging must be designed carefully so sensitive authentication data or prohibited contents are not captured.
Ask whether logs can be forwarded to the buyer’s monitoring platform using an agreed format. Define behavior when local storage fills, connectivity is unavailable, or time synchronization fails. Clarify who reviews alerts and within what operating hours. A log that nobody monitors is mainly forensic evidence, not timely detection.
Acceptance testing should generate controlled events and confirm they appear with correct actor, device, venue, action, result, and timestamp. Export a baseline and preserve configuration evidence. Ensure logs from the game, cashless device, firewall, and platform can be correlated through consistent identifiers.
Firmware integrity and secure updates
Connected products need a lifecycle update policy. Procurement should establish how firmware and software are authenticated, distributed, installed, verified, rolled back, and supported.
Ask whether code and update packages are cryptographically signed and whether the device verifies the signature before installation. Request a high-level description of secure boot or integrity checking where available, without demanding disclosure that would create security risk. Determine whether updates are automatic, scheduled, staged, manually approved, or remotely forced. Define maintenance windows and behavior when an update fails or power is interrupted.
The policy should state:
- supported product and software versions;
- minimum security-support period or a clearly defined end-of-support date;
- how vulnerabilities are reported and acknowledged;
- severity assessment and target communication process;
- advance notice for disruptive updates;
- testing and staged-deployment options;
- rollback and recovery methods;
- update logs and release notes;
- treatment of third-party and open-source dependencies;
- end-of-life migration options.
Avoid requesting an absolute promise that no vulnerability exists. Instead, require a repeatable vulnerability-management and disclosure process. Ask for a software bill of materials if available and appropriate to the risk, plus terms governing confidentiality and use.
NIST SP 800-213 is valuable here because it directs acquirers to connect device capabilities and supplier information with organizational cybersecurity needs. The buyer must still translate that framework into contractual requirements, evidence, and ownership.
Network segmentation and trusted onboarding
Do not place every attraction, office computer, camera, guest device, point-of-sale system, and building controller on one flat network. Segment systems according to risk and required communication. Default-deny rules should permit only necessary flows between defined sources and destinations.
A practical architecture may separate guest Wi-Fi, corporate administration, game devices, facilities systems, security cameras, and the cardholder data environment. Exact design depends on the venue, technologies, and local expertise. Segmentation must be implemented and tested; a VLAN label alone does not guarantee isolation.
For connected machines, require an asset inventory with owner, model, serial number, network identifier, software version, location, and support status. Establish an onboarding process that authenticates the device or installer, assigns it to the correct segment, applies policy, and records the change. NIST SP 1800-36 describes example trusted IoT device network-layer onboarding and lifecycle management approaches that can inform this design. It is a reference architecture, not a product endorsement or universal prescription.
Control outbound internet access through explicit destinations and services. Review DNS, NTP, certificate, cloud, remote-support, and update requirements. Avoid permanently opening broad inbound rules merely to expedite commissioning. Document fallback operation if a cloud service or WAN link fails.
Test segmentation at acceptance and after major network changes. Include attempts from guest and office networks, not just a successful connection from the intended segment. Preserve firewall configuration and test records.
PCI DSS responsibility boundaries
When payment-card data is involved, procurement must identify the cardholder data environment, payment channels, service providers, and contractual responsibilities. PCI DSS v4.0.1 is a limited revision to v4.0; the PCI Security Standards Council stated that it introduced no new or deleted requirements and did not change the 31 March 2025 effective date for future-dated requirements. Buyers should obtain current official documents from the PCI SSC document library rather than rely on summaries.
Do not assume that using a third-party payment terminal makes the entire venue “out of scope.” Scope depends on architecture, data flows, system connectivity, segmentation, and responsibilities. Equally, do not assume the arcade-machine manufacturer is responsible for every PCI requirement merely because a reader is mounted on its cabinet.
Create a responsibility matrix covering the merchant, acquiring bank, payment service provider, terminal provider, cashless platform, network integrator, venue operator, distributor, and machine supplier. Identify who handles device inspection, access control, network security, logging, vulnerability management, incident reporting, evidence, attestations, and changes.
Ask relevant providers for current PCI evidence appropriate to their role, but understand that a provider’s validation does not automatically validate the merchant’s implementation. Consult a qualified PCI professional for scope decisions. Contracts should require notice of changes that may affect scope or validation status.
Security incident and vulnerability clauses
Define incident and vulnerability notification channels, escalation contacts, evidence-preservation duties, affected-version identification, containment guidance, remediation updates, and post-incident cooperation. The buyer should maintain accurate asset contacts and apply agreed updates. Also require a responsible vulnerability-disclosure route and ask how reports are triaged and communicated to affected customers.
Exit, migration, and service discontinuation
Exit terms are a core security control because unsupported services and inaccessible accounts create risk. Negotiate them while alternatives still exist.
A complete exit schedule should cover:
- advance notice of service discontinuation where feasible;
- export of configuration, inventory, users, logs, events, and relevant history;
- machine-readable formats and schema documentation;
- API availability during transition;
- deletion or return of data and confirmation;
- credential, certificate, token, SIM, and domain-transfer responsibilities;
- removal of vendor remote access;
- local operation after cloud termination, including limitations;
- replacement or re-provisioning of readers and gateways;
- reasonable migration assistance and disclosed fees;
- handling of backups and legal holds;
- end-of-support risks and final firmware availability.
Test export before renewal, not only during a crisis. Import a sample into a neutral tool, confirm totals and identifiers, and document missing fields. Keep your own asset and configuration inventory rather than relying entirely on a vendor portal.
Procurement evidence package
Require an evidence package proportionate to risk. It may include architecture and data-flow diagrams, security questionnaire, account-role matrix, API documentation, update policy, support lifecycle, logging matrix, component inventory, privacy and data terms, incident process, available test summaries, and configuration hardening guide.
Evidence must match the quoted version. A report for a different gateway or old software release may still be informative, but the supplier should explain relevance. Protect genuinely sensitive documents through controlled access rather than omitting review entirely.
At factory or pre-deployment acceptance, verify interface inventory, unique device identifiers, absence or change of defaults, signed update behavior if offered, backup and restore, log generation, offline behavior, and secure reset. At site acceptance, verify network rules, time sync, role assignments, multifactor authentication where supported, remote-access approval, monitoring, and export.
Final procurement review
Before approval, confirm governance and data terms, complete architecture and data-flow diagrams, named accounts and least privilege, controlled remote support, central logging, update integrity and recovery, support lifecycle, tested segmentation, and a PCI responsibility matrix where payment data is involved. Sunflower can be asked for model-specific interfaces, component boundaries, update methods, and integration prerequisites. Third-party cashless or payment providers should answer for their own systems.
Häufig gestellte Fragen
1. Does a connected redemption machine automatically store personal data?
Not necessarily, but do not assume it does not. Inventory every data element and identifier, including logs and device-location records, then assess whether it identifies or can be linked to a person under applicable law.
2. Is an API the same as data portability?
No. Useful portability also requires historical coverage, workable rate limits, documented schemas, stable identifiers, export rights, and enough transition time. Require a bulk export independent of the live API.
3. Should arcade machines receive inbound internet access?
Only when a documented use case requires it and controls are defined. Prefer explicit, limited flows and controlled remote-access methods. Broad permanent inbound rules increase exposure.
4. What is signed firmware?
It is firmware accompanied by a cryptographic signature that a device can verify before installation. Ask how keys, verification, rollback, and recovery are managed for the quoted product; the label alone does not describe the complete control.
5. Does a PCI-validated payment provider remove the venue’s PCI duties?
No. The merchant’s scope and responsibilities depend on implementation, connectivity, segmentation, and provider relationships. Use official PCI SSC materials and qualified advice for the specific environment.
6. How long should security updates be provided?
There is no universal term for every machine. Buyers should negotiate a support period or defined end-of-support date that fits the expected service life, risk, and migration plan, and obtain it in writing.
7. Who should own administrator accounts—the distributor or venue?
It depends on the operating model, but the contract should preserve buyer control and prevent orphaned access. Use named roles, least privilege, auditable delegation, and a tested transfer/offboarding process.
8. What should happen when cloud service ends?
The buyer should be able to export data and configuration, revoke remote access, transfer relevant credentials or certificates, understand local-function limitations, and execute a documented migration or decommissioning plan.
9. Can network segmentation be assumed because devices use separate VLANs?
No. Verify firewall policy, routing, management access, shared services, wireless paths, and actual isolation through testing. Segmentation is an implemented and maintained control, not merely a diagram label.
