Visitor Management + Access Control: The Perfect Duo
Visitor Management + Access Control: The Perfect Duo Walk into any modern workplace today, and you’ll
Inside Spintly’s Credential Management Platform- Architecture, Flow, and Core Benefits
10 min reading time
Updated on May 05, 2026
Share this article
Table of Contents
In the first blog, we discussed why Scypher, Spintly’s credential management platform, exists and the problems it solves at scale. This blog focuses on the next question enterprise leaders usually ask:
How does Scypher actually work?
To answer that, we look inside Scypher’s architecture, its core components, and the path a credential follows from creation to enforcement.
What is Scypher Is (and Is Not)
Scypher is not an access control system. It does not replace controllers or decide whether a door opens. Scypher is a credential management platform.
Its job is to:
- Generate digital credentials
- Deliver them securely to users
- Manage their lifecycle
- Revoke them when required
The Core Design Principle Behind Scypher
Scypher is built on a simple but powerful idea:
Centralise credential management. Keep access enforcement local.
Traditional access control systems were designed in a world where credentials were physical cards. They work well when credentials are static and change infrequently. But modern enterprises operate very differently:
- People join and leave often
- Roles change frequently
- Temporary access is common
- Mobile devices are the primary identity carrier
Managing this level of change using manual or semi-manual workflows creates operational and security gaps.
Scypher addresses this by modernizing how credentials are managed without disrupting how access is enforced.
The Core Components of Spintly’s Credential Management Platform
Spintly’s credential management platform is made up of four core components. Each component has a clearly defined responsibility, and together they form the complete system.
1. Access Control System (ACS)
The Access Control System remains the system of authority.
It continues to:
- Manage users and identities
- Define access policies and permissions
- Decide which doors a user can access
- Communicate directly with controllers
Scypher does not override or replace the ACS. Instead, it works alongside it. Whenever a credential is required, the ACS initiates the request and remains responsible for permission assignment.
2. Spintly Credential Server
The Spintly Credential Server is the cloud-based component of the platform.
Its role is to manage the credential lifecycle, which includes:
- Receiving credential requests from the ACS
- Generating secure digital credentials
- Maintaining credential state (active, suspended, revoked)
- Acting as the central source of truth for credential validity
What the Credential Server deliberately does not do:
- It does not define access permissions
- It does not communicate with door locks
- It does not participate in door-opening decisions
Think of it as the system that creates and manages credentials, not the system that enforces access.
3. Spintly Mobile SDK
The Spintly Mobile SDK is how credentials reach users’ phones.
Instead of requiring users to install a separate Spintly app:
- Enterprises or integrators use their own mobile app
- The Spintly SDK is embedded inside that app
The SDK handles:
- Securely fetching credentials from the Credential Server
- Storing credentials on the device
- Supporting multiple access modes such as NFC tap, BLE-based access, QR-based access, and tap/click based intent flows
- Communicating with the reader during authentication
From a user’s perspective, access feels like a native feature of the app they already use. From a system perspective, the SDK acts as a secure carrier for digital credentials.
4. Spintly Reader and Existing Controllers
At the physical access point, Scypher integrates into the existing infrastructure.
- The Spintly Reader is installed at the door
- In most enterprise environments, it runs in reader mode
- It connects to the existing controller using standard wired interfaces
The reader’s responsibility is straightforward:
- Read the credential presented by the phone (NFC, BLE, or QR)
- Transmit the credential ID to the controller
The controller:
- Stores credentials locally
- Validates permissions
- Makes the final access decision
- Unlocks the door if access is allowed
In some deployments especially new buildings, the reader can also act as a controller. However, Scypher does not assume this model and works seamlessly with existing controllers.
How Credentials are Issued
To understand how these components work together, let’s walk through the credential issuance and access flow.
Step 1: Credential Request
When a user needs access:
- The Access Control System initiates a credential request
- This request is sent to the Spintly Credential Server
At this stage, no access is granted. A credential is simply being requested.
Step 2: Credential Generation
The Credential Server:
- Authenticates the request
- Generates a secure digital credential
- Returns the credential to the ACS
The credential now exists, but it is not yet active at the door.
Step 3: Permission Assignment and Controller Update
Back in the ACS:
- Access permissions are assigned to the credential
- The credential is registered with the controller
- The controller stores the credential and its permissions locally
This step ensures that access enforcement remains local and reliable.
Step 4: Credential Delivery to the User
On the user side:
- The enterprise mobile app requests credentials
- The Spintly SDK fetches the credential using the user’s unique identifier
- The credential is securely stored on the phone
There is no physical card issuance, printing, or handover involved.
Step 5: Access at the Door
When the user approaches the door:
- The phone communicates with the Spintly Reader
- The reader reads the credential ID
- The credential ID is sent to the controller
- The controller validates permissions and unlocks the door if allowed
Scypher is not involved in this real-time decision. The controller always decides.
In short:
How Credential Revocation Works
Revocation follows the same clear separation of responsibilities.
When access needs to be removed:
- The credential is revoked centrally via Scypher
- The ACS updates the controller
- The controller removes the credential from its local database
Even if:
- The phone is offline
- The app is not running
Access will fail, because the controller no longer recognises the credential. This preserves the same security guarantees enterprises expect from traditional access control systems.
Why This Architecture Works at Enterprise Scale
Spintly’s credential management platform works because it respects real-world enterprise constraints:
- Controllers are already deployed and trusted
- Wiring is already in place
- Access policies are already defined
- Change needs to be gradual, not disruptive
By separating credential management from access enforcement, Scypher allows enterprises to adopt mobile access and modern credential workflows without destabilising existing systems.
Core Benefits of This Approach
For security teams:
- Faster credential issuance and revocation
- Reduced risk from lost or shared cards
- Cleaner audit trails
For IT and engineering teams:
- No controller replacement
- No rip-and-replace migration
- API-driven integration
- Flexible rollout across buildings
For operations:
- Fewer manual exceptions
- Less dependency on physical card handling
- Better coordination between systems
At its core, Scypher is built around a simple realization: access control doesn’t break at the door, it breaks in how credentials are managed over time.
As enterprises grow, people join, move roles, take on temporary access, and leave. When credentials are still handled through manual or fragmented workflows, even the most reliable access control systems start to feel harder to manage. Delays creep in. Exceptions become routine. Risk quietly increases.
Scypher was designed to solve this exact problem.
By separating credential lifecycle management from access enforcement, Scypher modernises how credentials are issued, delivered, and revoked without disturbing the controllers, wiring, and access logic that enterprises already trust. The door continues to behave the same way. The controller continues to make the final decision. What changes is everything behind the scenes.
The result is a system that scales naturally with the organization: faster onboarding, cleaner revocation, better visibility, reduced costs and fewer operational dependencies without forcing disruptive infrastructure changes.
In short, Scypher doesn’t ask enterprises to rethink access control. It simply makes credential management finally catch up to how modern organizations actually operate.
