Payment-device access fundamentals
Payment devices should not share default passwords because a password reused across many units does not reliably distinguish an authorized administrator from anyone else who knows or discovers that common credential. If one shared password is exposed, every device still using it may face the same access risk.
CISA defines default passwords as universally shared passwords present by default across a product and recommends replacing them with stronger authentication, such as random, instance-unique passwords. For a merchant, the practical goal is straightforward: each supported payment device and each person with administrative access should be identifiable, access should be limited to the work required, and credentials should be managed through the device provider's approved process.
A factory or installer credential can simplify initial setup, but leaving the same value active across deployed devices turns one secret into a common point of failure. The credential may appear in setup material, be known by former staff, be reused at another location, or become available to an attacker. Changing the password on only some devices also makes it difficult to know which units remain exposed.
A shared login weakens accountability as well. When several people use one administrator identity, activity records may show the account but not the person who made a configuration change. Unique accounts and device-specific credentials make access reviews, offboarding, and investigation more useful. They do not prevent every incident, but they reduce reliance on a single reusable secret.
Confirm whether each device has its own administrator credential, how the initial value is delivered, and whether the product requires a change during setup. Follow current manufacturer or provider instructions for the exact model and payment application.
When the platform supports named users, give each authorized worker an individual account instead of a shared staff login. Assign only the permissions needed for that role and remove access promptly when responsibilities change.
Ask who can connect remotely, how access is authenticated and approved, whether it is limited by time or role, and what records are available. Do not enable an undocumented backdoor or share a password in response to an unexpected support request.
Do not guess at hidden menus, install unofficial software, or perform an unverified factory reset to remove a default credential. A reset can affect configuration, payment applications, connectivity, keys, records, or provider support. Identify the exact device model and responsible provider, then use their current deployment, password-change, and recovery instructions.
If a device cannot support a unique credential, named users, or another documented access control, record that limitation and ask the responsible provider for a supported mitigation or replacement path. CISA's guidance places strong emphasis on products that eliminate universal defaults, while NIST's device cybersecurity baseline treats authorized configuration and logical access as core capabilities. Those sources describe general security principles; they do not establish that a particular terminal supports a feature.
Record the model, serial or asset reference, physical location, payment application, network connection, responsible provider, and current support status without copying passwords into the inventory.
List the roles that need local or remote administration, the approved support channel, and the person who can authorize changes. Remove accounts or privileges that no longer match current responsibilities.
Use the provider-approved procedure. Prefer unique, randomly generated credentials stored in an organization-approved password manager, and enable provider-supported multifactor authentication where available.
Confirm that the old credential no longer works, normal payment operations continue, and recovery instructions are available to authorized staff. Record the change date and owner, not the secret itself, in the operating log.
A legitimate-looking call, email, or screen message is not enough to establish identity. If someone requests a device password, one-time code, remote-control session, or configuration change, stop and verify the request through a known portal, contract, statement, or previously confirmed support number. Do not use contact details supplied only by the incoming message.
Keep passwords out of labels attached to the terminal, shared spreadsheets, tickets visible to broad groups, chat transcripts, and general inquiry forms. Limit physical access to devices, keep supported software current through verified channels, and review administrator accounts on a regular schedule. If an unknown person may have used a credential, contact the responsible provider through a trusted channel and follow the business's documented response process.
Start with the device inventory, the people and providers that administer each unit, the approved change process, and the recovery plan. Payments Max can help organize these operational questions as part of a broader payment-equipment review, without claiming that a particular control is available for every device.
Do not submit cardholder data, complete account numbers, bank credentials, device passwords, one-time codes, recovery secrets, or API keys through a general inquiry form.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US
