Axxession
A hand holding a badge flat on a reader
Key custody

One credential, and who holds the keys to it

Both models work. Which one you can have depends on your controllers and readers, and never on us. Whichever model your systems allow, the keys are yours, held by you, escrowed to you, never ours to keep.

Key Management

DESFire key management, SAM and vSAM key custody

The platform moves encoding instructions, and never the keys themselves. No encoding point ever holds a key.

2 custody models

Both work. Which one you can have depends on your readers.

Preferred · SAM or vSAM

Keys live in a secure module, never in the readers themselves.

  • No key reaches a door. A stolen reader gives up nothing
  • Rotating or revoking a key is 1 controlled act, with no site visit
  • The custody chain is documented, which is what an auditor asks for
  • Multiple key sets rotate a key without a second badge campaign

Needs controllers and readers that support a SAM, or a hosted vSAM service.

Also supported · keys in the readers

The classic model, and still the right answer on many installations.

  • Works with reader families that have no SAM slot
  • No dependency on a module or a hosted service
  • Familiar to the installer base already on site
  • You agree a credential specification once: application, file, format and key number, and never again

Key rotation means touching every reader, and configuration cards are themselves a target.

Whichever model your systems allow, the keys are yours, held by you, escrowed to you, never ours to keep.

Key custody in practice

The platform moves encoding instructions, and never the keys

1 vault per key owner. No point where encoding happens ever holds a key.

Where the keys live. One vault per key owner

Your vSAM

Your DESFire keys, on your own infrastructure. Nobody else can read them.

A second organisation's vSAM

A landlord, a tenant or a partner keeps its own keys, in its own vault.

Your integrator's vSAM

Where you prefer a partner to hold and operate the vault for you.

Where encoding happens, none of these holds a key

Desk encoder

At a badge desk or reception, for one-time issuing or re-encoding.

Self-service terminal

Unattended exchange, issue and return, at any hour.

Edge controller on site

For volume runs and re-encoding campaigns across a population.

SAM in controller or reader

Programmed remotely. A key change is not a site visit.

One badge can carry more than one organisation's keys. A tenant's own credential re-encoded at reception with the landlord's read key, without either party ever seeing the other's keys.

Questions

Frequently asked questions

Who holds our credential encryption keys?

You do. Keys live in a vault or secure module under your control. Your own vSAM, your integrator's, or a SAM in your controllers. They are held by you and escrowed to you, and are never ours to keep.

What does the platform send to an encoder?

The encoding profile and the authorisation for that session. The keys stay where they are. No encoding point in the chain, including desk encoders, terminals and edge controllers, holds a key.

If a key leaked, would we have to visit every reader?

With a SAM or vSAM model, no. Rotating or revoking a key is one controlled act, and multiple key sets let you rotate without a second badge campaign. With keys held in the readers, rotation does mean touching every reader. Which is the main reason we prefer the module.

Can one badge carry keys from 2 organisations?

Yes. A tenant's own credential can be re-encoded at a landlord's reception with the landlord's read key, without either party ever seeing the other's keys.

The first step

Start with 1 site and 1 population.

You judge something that runs on your own site. Your access systems and readers stay where they are. If it earns its place, we extend it site by site.

One siteOne populationYour readers stay