CommBox Autofill does not trade security for convenience

Cyber security is never simple. It is a constantly evolving discipline of understanding risk, designing layered controls, testing assumptions and improving as both technology and threats change.

But complexity cannot become an excuse to stand still.

Schools and workplaces need technology to advance. They need experiences that are faster, more intuitive and easier to use—and they should not have to accept weaker security to get them. The real challenge for a technology company is not to choose between innovation and security. It is to make each strengthen the other.

That is where CommBox excels.

CommBox Autofill was developed around a real-world challenge: how to make sign-in on a shared, large-format display faster and easier without weakening the controls that protect a user’s authentication.

That includes supporting modern authentication methods such as passkeys, as well as providing a secure Autofill experience for applications and websites that still require a username and password.

CommBox is not trying to preserve passwords as the future of authentication. Where passkeys are supported, users should be able to take advantage of them. Where passwords are still required, CommBox believes they should be handled with the same level of deliberate security engineering.

The answer was not to remove security controls in the name of convenience. It was to redesign the experience so that the improvement came from reducing exposure, not reducing protection.

Of course, innovation is not, by itself, evidence of security. A feature earns trust through its architecture, the controls placed around it and the testing used to validate it. That is why Autofill should be assessed on how credentials are protected, when and where they can be used, what additional authentication is required, and whether the design has been independently tested.

Recently, there has been commentary in the interactive display market suggesting that any feature capable of filling a username and password must be inherently unsafe.

That may sound intuitive, but it is not a serious security analysis.

Every sign-in already involves credentials. On a 75-inch or 86-inch shared display, manually entering a password can create its own very visible risks. It can expose keystrokes to a room, encourage people to use shorter or more memorable passwords, and force users to balance security against the practical need to begin a lesson or meeting quickly.

The right question is not:

“Does this workflow involve a password?”

The right questions are:

How is the credential protected? When can it be used? Where can it be used? What additional authentication is required? Has the design been independently tested?

That is how CommBox approached Autofill for the CommBox Classic S5.

Secure innovation is a design discipline

Secure innovation does not mean developing a feature first and attempting to add security around it later.

It means treating security as part of the product design from the beginning: minimising exposure, limiting where sensitive information can be used, requiring deliberate user authentication, restricting access in time and independently testing the result.

Security is not advanced by refusing every useful capability that interacts with sensitive information. It is advanced by solving the engineering problem properly.

That is the difference between innovation that simply introduces a new feature and innovation that deserves trust.

CommBox Autofill was designed around the latter.

Passkeys are part of that secure innovation

Authentication is evolving.

Passkeys provide a modern alternative to traditional passwords and can deliver important security and usability benefits. Where an application or service supports passkeys, the CommBox Vault supports them as part of the Autofill experience.

That matters because secure innovation should not force every user into a single authentication method.

Some services support passkeys. Some use Google or Microsoft SSO. Others still require a username and password, often together with multifactor authentication.

A modern shared-device platform needs to accommodate that reality securely.

CommBox Autofill is therefore not simply a mechanism for storing and entering passwords. It is part of a broader authentication experience designed to make secure access easier across the different authentication methods customers actually encounter.

Passkeys reduce reliance on passwords. SSO delegates authentication to an identity provider. Autofill securely addresses services that still require credentials.

These methods are technically different, but the engineering principle remains consistent:

Use the strongest authentication method available, minimise exposure of authentication material, constrain how it can be used and protect the user throughout the session.

That is a much stronger position than simply declaring one authentication method “safe” and another “unsafe”.

SSO changes the secret; it does not eliminate it

It is sometimes implied that signing in with Google or Microsoft SSO is inherently safe because the platform does not receive the user’s password, while a controlled Autofill capability must be inherently unsafe because it uses one.

That is not an accurate comparison.

SSO is an important and effective security mechanism. CommBox uses it. It allows Google or Microsoft to perform the primary authentication, apply the organisation’s multifactor authentication requirements and enforce its identity policies.

But SSO does not mean that the receiving platform (ie CommBox OS or any other Interactive Screen brand) handles no security-sensitive authentication material.

After a successful SSO login, the platform receives tokens. An access token authorises requests to permitted services. A refresh token may allow the platform to obtain further access tokens without asking the user to sign in again.

Many access tokens operate as bearer credentials. In practical terms, the system accepts possession of the valid token as authority to perform the actions allowed by that token. The user is not required to enter their username, password and multifactor challenge again for every request. That is precisely what allows an SSO session to function.

This does not make SSO unsafe. It means the tokens must be protected.

Passwords and tokens are technically different. Tokens can be scoped to particular services, bound to an intended audience, limited in duration and revoked without changing the underlying password. Those are meaningful security advantages.

But both passwords and tokens remain security-sensitive secrets. If either is exposed, the consequences depend on what it can access, how long it remains valid and what controls surround it.

The relevant security questions are therefore the same:

Where is the secret stored?How is it encrypted?Which application or service can use it?How long is it available?Can it be retrieved or copied?How is the session terminated?What happens to local data when the session ends?

Every interactive display platform offering Google or Microsoft SSO must answer those questions. The same is true of any competing platform offering those sign-in methods.

The platform must receive, use and protect tokens during the authenticated session.

That is not a criticism of SSO. It is simply how delegated authentication works.

CommBox already handles this exceptionally well. CommBox OS uses Google and Microsoft OAuth login flows, protects identity-provider access and refresh tokens in Azure Key Vault, applies .NET data-protection services to JWT tokens and validates signed tokens on the server. Sensitive tokens are not exposed in API URLs.

During a CommBox OS Account session, the display necessarily uses tokens to validate requests and, where permission has been granted, to establish the user’s OneDrive or Google Drive connection and with Huntsmen release Teams Shared Drives and Google Workspace Drives. The session is time-limited, and at its conclusion CommBox OS clears the user’s local session data, including cloud-drive application data, browser history, application data and whiteboard data. A user can also remotely terminate an active display session through the CommBox Experience portal.

Autofill applies the same security discipline across different authentication scenarios.

Where passkeys are supported, the CommBox Vault can support a modern passwordless authentication experience. Where Google or Microsoft SSO is available, CommBox supports delegated authentication through those identity providers. And where a service still requires a username and password, Autofill provides a controlled way to use that credential without unnecessarily exposing it to the user or the room.

The objective is not to promote one authentication method at the expense of another. It is to support the strongest practical authentication method available for each service, securely.

SSO is an excellent option where an application or website supports the organisation’s Google or Microsoft identity provider. But not every application supports the same SSO provider, tenant configuration or authentication method. Users still encounter services that require a username and password.

CommBox Autofill securely addresses that gap.

Instead of requiring a user to type a password onto a large display in front of an audience, Autofill allows the credential to be used for its intended purpose without turning it into a generally retrievable secret.

The password cannot be displayed through the online vault. It can only be released after the user enters the vault PIN, and only to the application or website to which it was assigned. Application signatures are validated, websites are destination-bound, browser support is restricted to a vetted list, the vault automatically relocks after five minutes, and the user’s PIN is not retained by CommBox.

Autofill and SSO are therefore not opposing categories—one safe and one unsafe.

They are two methods of enabling authenticated access. One relies on carefully protected tokens issued by an identity provider. The other relies on a carefully protected credential released only to its approved destination.

In both cases, security comes from the architecture and the controls—not from the name given to the authentication method.

A vault designed for use, not disclosure

CommBox Autofill is not a general-purpose password viewer.

Nor is the CommBox Vault limited to passwords.

The Vault also supports passkeys, allowing users to take advantage of passwordless authentication where the destination service supports it.

This is an important distinction. CommBox is not building an experience around the assumption that passwords will always be the preferred authentication method. The Vault is designed to support the transition towards stronger and more convenient authentication while still securely handling the applications and websites that depend on traditional credentials today.

It allows a user to assign credentials to an approved application or website for use during that user’s authenticated CommBox OS session.

Importantly, the online vault does not display the stored password. Once the user has entered and saved a password, it cannot be revealed back through the portal. The user can replace it with a new password, but cannot retrieve the existing password in clear text.

This is consistent with a fundamental principle of modern secrets management: a system should be able to use a secret for a tightly defined purpose without unnecessarily exposing the secret itself.

Reducing the number of places in which a password can be displayed, copied or disclosed is a security control—not a security weakness.

Multifactor authentication remains in control

Accounts added to the CommBox Autofill vault are required to have multifactor authentication enabled.

Autofill can supply the stored username and password. It does not disable or bypass the target service’s MFA policy. The relevant identity provider still controls whether and how the user must complete the second-factor challenge.

The Autofill vault is protected separately by a master PIN. On the CommBox Classic S5, the user must enter that PIN before Autofill can operate. The vault then remains unlocked for only five minutes before automatically locking again.

It is worth being technically precise about this.

The target account’s MFA provides the independent second factor. The vault PIN is an additional gate controlling access to the stored credential. These controls perform different functions, and together they provide layered protection.

The password is therefore not sitting on a classroom display waiting to be used by anyone who approaches it.

Credentials are bound to their intended destination

One of the most important security controls in Autofill is that a credential cannot simply be selected and inserted anywhere.

For Android applications, credentials are assigned to a curated list of trusted applications. CommBox validates the application signature before releasing the credential, helping prevent a rogue application from impersonating the legitimate app.

For websites, the credential is bound to the website with which it was associated. Web-based Autofill is also limited to vetted browsers.

This means the system is designed to prevent a user—or a malicious application—from taking a credential intended for one service and directing it into an arbitrary application or website.

That destination binding is critical. It directly addresses one of the central risks in any credential workflow: ensuring that the secret is released only to the intended recipient.

Shared-device sessions are temporary

Autofill operates within a personal CommBox OS Account session.

Users select a session duration when they sign in. At the end of that session, CommBox OS clears the user’s associated data from the display, including browser history, application data, cloud-drive session data and whiteboard data.

A user who leaves a room before the session expires can also remotely log out of the display through the CommBox Experience portal.

This is particularly important in schools and shared workplaces. Security cannot rely on every person remembering to manually clean up every application after every session. The platform should perform that work by design.

The wider platform also protects the data

Autofill does not operate as an isolated feature.

The wider CommBox OS Experience environment uses encryption in transit with TLS 1.3 and perfect forward secrecy, together with AES-256 encryption for data at rest.

CommBox also applies application logging, access controls, secure cloud infrastructure and web application firewall protections as part of the broader platform architecture.

Security is strongest when it is layered. No single control is expected to carry the entire burden.

CommBox did not mark its own homework

In October 2025, CommBox engaged Trustwave SpiderLabs to perform an independent application penetration test of the Autofill APIs before it was released.

The assessment examined both authenticated and unauthenticated attack surfaces. Trustwave used automated tools and manual testing techniques, prioritising critical security controls, sensitive information and areas that commonly create application risk.

The testing considered areas including:

• authentication and authorisation;

• session management;

• data protection and transport;

• credential and account controls;

• injection attacks;

• workflow and business-logic abuse; and

• cryptographic implementation.

The result was clear.

Trustwave reported that it found no vulnerabilities within the Autofill application during the testing period. It also reported no significant vulnerabilities or configuration weaknesses and found no direct evidence that the Autofill APIs were at significant risk of compromise.

A separate penetration test of the CommBox OS device environment reached the same high-level conclusion: no significant vulnerabilities or configuration weaknesses were identified.

That is substantially more meaningful than asking customers to “trust us”.

It is independent evidence.

Good security does not rely on absolute claims

No credible cyber security professional should describe any connected system as permanently “unhackable”.

Security testing is a point-in-time assessment. New attack techniques emerge, underlying technology changes, and new vulnerabilities can be discovered. That is why mature technology companies test repeatedly, maintain secure development practices, review cloud configurations, manage vulnerabilities and improve their controls over time.

Trustwave recommended that CommBox continue its program of periodic assessments. CommBox agrees.

That qualification does not weaken the security case. It strengthens it, because it distinguishes responsible security governance from marketing theatre.

Look at the complete workflow

When someone claims that Autofill is unsafe simply because it handles a credential, customers should examine the complete design.

• Can an ordinary portal user reveal the stored password? No.

• Is the credential intended to be filled into an arbitrary application or website? No.

• Does Autofill bypass the target account’s MFA controls? No.

• Does the vault remain indefinitely unlocked? No.

• Has the Autofill API been independently penetration tested? Yes.

• Does Google or Microsoft SSO mean that no authentication secret is handled by the display? No. The display must use tokens during the authenticated session.

• Does that make SSO unsafe? No. It means those tokens must be encrypted, constrained, validated, time-limited and cleared securely - so you know if this a done correctly by the Interactive Display brand you are evaluating.

• Does Autofill allow a stored password to be viewed, copied or released to an arbitrary destination? No.

• Does CommBox Autofill only support username and password authentication? No. The CommBox Vault also supports passkeys where the destination service supports them.

• Does CommBox force users to use a stored password when a stronger authentication option is available? No. CommBox supports different authentication methods, including passkeys and Google or Microsoft SSO, depending on what the destination service supports.

The simplistic claim that “SSO is safe because it uses a token, while Autofill is unsafe because it uses a password” does not withstand technical scrutiny.

The correct comparison is between the complete security properties and controls surrounding each authentication method — whether that is a passkey, Google or Microsoft SSO, or a username and password.

Passkeys are an important advancement and CommBox supports them. SSO is an important authentication mechanism and CommBox supports it. Passwords remain necessary for many applications and CommBox Autofill protects them.

Supporting modern authentication should not mean pretending older authentication methods no longer exist. Secure innovation means dealing with both realities properly.

A real comparison is between manually typing that credential on a large shared display and using a credential workflow that is:

• protected by the account’s MFA;

• gated by a separate vault PIN;

• unavailable for online password viewing;

• limited to approved applications and websites;

• automatically relocked;

• encrypted;

• contained within a temporary user session; and

• independently penetration tested.

CommBox Autofill does not trade security for convenience.

Nor does CommBox confuse a change in credential format with the elimination of security risk.

Whether a system is handling a Google or Microsoft token, a session token or a credential stored for Autofill, it is handling security-sensitive authentication material. The responsibility is to minimise its exposure, encrypt it, constrain its use, validate its destination, limit its lifetime and remove it when the session ends.

CommBox already applies those principles to Google and Microsoft SSO.

CommBox is also embracing the next generation of authentication through passkey support in the CommBox Vault.

And for the many applications and websites that still require a username and password, Autofill applies the same disciplined approach. It preserves the target account’s multifactor authentication, adds a separate vault PIN, prevents the password from being revealed through the portal, restricts its use to an approved destination, automatically relocks the vault and contains activity within a temporary user session.

That is what secure innovation looks like in the real world.

It is not about declaring passwords bad, SSO good, or passkeys the answer to every authentication scenario.

It is about recognising that customers operate across all three today — passkeys, federated SSO and traditional credentials — and engineering each experience appropriately.

CommBox gives customers access to modern authentication when it is available, while securely solving the authentication challenges that still exist when it is not.

Autofill applies the same disciplined approach to applications and websites that still require a username and password. It preserves the target account’s multifactor authentication, adds a separate vault PIN, prevents the password from being revealed through the portal, restricts its use to an approved destination, automatically relocks the vault and contains activity within a temporary user session.

It has then subjected those controls to independent penetration testing.

That is the important distinction.

Secure innovation is not achieved by supporting fewer useful authentication methods and declaring the remaining method inherently safe. It is achieved by understanding the security properties of each method and engineering the right controls around it.

Customers should not have to choose between a better experience and serious security.

CommBox demonstrates that they can have both.

Security should be tested, not asserted.

CommBox has done the testing.