Badge & Access Control Modernization
Replacing DL-Windows with a custom, FedRAMP-aligned badge management platform that integrates bidirectionally with Okta via SCIM and eliminates manual credential workflows.
Current State & Risk Exposure
Our physical access control system relies on Alarm Lock Trilogy locks (DL6200 and DL1300NW series), HID ProxCard II credentials, and DL-Windows v5.5.3 for management. While functional, this system carries significant security and operational risks that are increasingly misaligned with our FedRAMP posture.
How HID ProxCard Works (and Why It Is a Problem)
HID ProxCard II operates at 125 kHz and broadcasts an unencrypted bit stream containing only a facility code and card number. There is no mutual authentication, no session encryption, and no tamper detection. The same data is transmitted identically every time the card enters a reader's field.
Cloning risk is not theoretical. Devices like the Proxmark3 ($50-$200) or handheld card copiers ($20) can read and duplicate any HID ProxCard in seconds from several feet away. An attacker in an elevator or hallway can clone a badge without physical contact.
This technology was designed in the 1990s and has no cryptographic protections. It is the physical access equivalent of transmitting passwords in plaintext.
Immediate Savings: Card Supplier Switch
Independent of any platform changes, we are significantly overpaying for proximity cards. We currently purchase Farpointe Data PSC-1-H clamshell cards at $5.78/card. These are HID-compatible 26-bit Wiegand cards. The same specification is available from multiple suppliers at substantially lower prices.
| Supplier | Card | Per Card (100 qty) | Per Card (500 qty) |
|---|---|---|---|
| Current (Farpointe via Farpoint Data Inc) | PSC-1-H Clamshell | $5.78 | $5.78 |
| Easy Badges | HID ProxCard II (genuine HID) | ~$2.65 | ~$2.40 |
| BadgeBuddies | HID ProxCard II (genuine HID) | ~$4.04 | ~$3.23 |
| EZProximity | HID-compatible 26-bit | ~$2.39 | ~$2.00 |
Zero-risk savings: All 26-bit H10301 Wiegand cards are interchangeable regardless of manufacturer. Our Trilogy locks read the facility code and card number from the RF signal, not the brand. Switching suppliers requires no infrastructure changes, no reprogramming, and no testing. At 200 cards/year, switching to the lowest-cost supplier saves $676-$756/year immediately.
Prerequisite: Gateway Deployment
Our Trilogy DL6200 and DL1300NW locks have built-in 900 MHz radios designed to communicate wirelessly with Networx gateway devices. These gateways are not currently deployed. As a result, every credential change (adding a user, removing a terminated employee, updating a schedule) requires the facilities manager to physically walk to each lock with a laptop and cable.
Current deprovisioning workflow: When an employee is terminated, the facilities manager must walk to every door the employee had access to, connect the AL-PCI2-U cable to each lock, and individually remove the credential. In a multi-building environment with dozens of doors, this takes hours to a full day. During this entire window, the terminated employee's badge continues to open every door that hasn't been reached yet.
Gateway deployment is a prerequisite for both Plan A and Plan B. Without gateways, there is no wireless path to push credential changes to the locks, regardless of what software manages the process.
Why Gateways Were Not Deployed
The gateways were not deployed due to security concerns about adding wireless devices to the network. These concerns are understandable but do not hold up against the actual security architecture of the devices or the risk created by not deploying them.
Addressing the Security Concerns
The 900 MHz Link Is Not WiFi
The gateway-to-lock communication uses a proprietary 900 MHz radio protocol with AES-128 encryption. This is categorically different from WiFi or Bluetooth:
- Proprietary protocol — not a published standard. No off-the-shelf attack tools exist for it.
- Frequency hopping across a 26 MHz band (902-928 MHz), making interception of a complete session extremely difficult.
- AES-128 encrypted payload — even if captured, the data cannot be read without the encryption key.
- Requires specialized SDR hardware to even monitor 900 MHz traffic. This is not something an attacker does casually.
- Zero published vulnerabilities. No CVEs, no security advisories, no penetration testing research exists against the Networx 900 MHz protocol.
The Gateway Network Footprint Is Minimal
The gateway is a low-power embedded device (Lantronix network module), not a general-purpose computer. Its network exposure:
- Port 10001 (TCP) — communication with DL-Windows. This is the only port needed for operation.
- Port 80 — web interface for initial configuration only. Can be firewalled off after setup.
- No internet access required. The gateway only needs to reach the DL-Windows server on the LAN.
- No cloud connectivity, no outbound traffic, no third-party dependencies.
Recommended Network Configuration
- Dedicated VLAN — place all gateways on an isolated security/IoT VLAN, separate from general IT traffic
- Firewall rules — allow only port 10001 between the gateway VLAN and the access control management server. Block everything else.
- Static IP addresses for each gateway (Napco recommendation)
- Block internet-bound traffic from the gateway VLAN entirely
- Disable the web interface (port 80) after initial configuration via firewall rule
- Wired gateways only — use AL-IME or AL-IMEPOE (Ethernet), not the WiFi models, to eliminate any wireless-on-wireless concern
Enterprise validation: Lenel OnGuard (one of the largest enterprise access control platforms) certifies Trilogy Networx locks through their OpenAccess Alliance Program. The integration uses the exact same gateways with the exact same 900 MHz protocol. There is no "enterprise-grade" alternative gateway. If the security is sufficient for Lenel-certified enterprise deployments, it is sufficient for ours.
The Real Security Risk
Not deploying gateways creates far greater risk than deploying them
- Terminated employees retain physical access for hours to days while the facilities manager walks building-to-building
- No real-time audit trail — door access events are stored locally on each lock and must be manually downloaded
- No remote lockdown capability — cannot execute an emergency lockdown without physically visiting each door
- No centralized visibility — a security incident investigation requires physically visiting each lock to pull logs
- FedRAMP PE-3 compliance gap — manual, multi-hour deprovisioning does not meet the standard for enforced physical access authorizations
The theoretical risk of a VLAN-isolated embedded device running a proprietary encrypted protocol is orders of magnitude lower than the operational risk of delayed deprovisioning, no audit trail, and no emergency lockdown.
Gateway Costs
| Item | Unit Cost | Quantity | Total |
|---|---|---|---|
| AL-IMEPOE (PoE Ethernet Gateway) | $300 - $500 | 2-4 (one per coverage zone, ~100ft range each) | $600 - $2,000 |
| Wireless expanders (if needed for range) | $150 - $250 | 0-4 (extends range ~175ft per unit) | $0 - $1,000 |
| Network switch ports / PoE | Existing infrastructure | 2-4 ports | $0 |
| VLAN configuration | Internal labor | 1-2 hours | $0 |
| Total Gateway Deployment | $600 - $3,000 | ||
Labor Savings from Gateway Deployment
Even without any new software platform, gateways alone transform the deprovisioning workflow:
| Operation | Without Gateways (Current) | With Gateways |
|---|---|---|
| Deprovision one employee (all doors) | 30 min - 2 hours (walking to each lock) | 2 minutes (remove in DL-Windows, auto-sync) |
| Provision one new badge (all doors) | 30 min - 2 hours | 2 minutes |
| Emergency lockdown | Not possible remotely | ~10 seconds to all locks |
| Download audit logs | Visit each lock individually | Pull from DL-Windows centrally |
| Terminated employee access window | Hours to days | Minutes |
Conservative labor estimate: If the facilities manager handles ~200 credential changes per year and each currently takes an average of 45 minutes of walking/connecting vs. 2 minutes with gateways, that is 143 hours/year saved — roughly $7,150/year at $50/hr. The gateway hardware ($600-$3,000) pays for itself within the first few months.
What This Costs Us Today
We already have a functioning badge system. The issue is not whether we control physical access, but how much manual effort it takes to maintain, how long gaps persist when people leave, and how well our process holds up under FedRAMP scrutiny.
The Deprovisioning Gap
This is the highest-impact operational risk. When an employee is terminated, their Okta account can be disabled in minutes. But their physical badge continues to work until someone manually removes the credential from DL-Windows and syncs to the locks. There is no automated trigger, no alert, and no SLA on this process. The gap is however long it takes someone to remember to do it.
FedRAMP Audit Friction
FedRAMP PE-3 requires enforced physical access authorizations, audit logs of all access events, and annual review of physical access devices. Our current process relies on manual coordination between disconnected systems. Demonstrating compliance requires assembling evidence from multiple sources (DL-Windows exports, Okta logs, manual records) rather than pulling from a single auditable system.
This proposal does not prevent a breach that our current system would miss. What it does is close the operational gaps (deprovisioning speed, audit completeness, process automation) that create risk and consume labor hours.
Plan A: DL-Windows SQL Pipeline
Use DL-Windows as a Sync Engine
Build our own platform for everything except the last-mile lock communication.
DL-Windows v5.5.3 stores all credential, user, and schedule data in a Microsoft SQL Server Express database (instance: ALSQLEXPRESS2012). This is a standard SQL Server instance accessible with any SQL client.
We build a modern web application that handles the entire badge lifecycle (Okta sync, user management, badge design, prox encoding, credential assignment, audit trail) and writes credential data directly to the DL-Windows database. DL-Windows then syncs those credentials to the Trilogy locks via the existing Networx gateway infrastructure.
What We Build
Custom Badge Management Platform
- Okta SCIM Sync (Inbound) - Pull user data (name, department, title, photo) from Okta. Users provisioned in Okta are automatically discoverable in the badge platform
- Credential Assignment - Auto-assign next available card number from our facility code range
- Badge Design & Printing - Template engine for photo ID badges, send to Bodno printer
- Prox Encoding - Encode HID-compatible 125 kHz credentials (if Bodno has encoder module) or via standalone encoder
- DL-Windows DB Sync - Write user/credential/schedule records to the SQL Server database
- Okta SCIM Integration - Bidirectional sync with Okta. Users from Okta are discoverable in the app; Badge IDs are written back to Okta as a custom attribute, making them discoverable in the Okta directory
- Audit Trail - Full lifecycle logging: who was provisioned, when, by whom, what changed
- Deprovisioning Automation - When Okta account is disabled, immediately flag or remove credential from DL-Windows DB
What We Keep
Existing Infrastructure (No Changes)
- Trilogy DL6200 and DL1300NW locks - No replacement, no reprogramming
- Networx gateways (AL-IME/AL-IMEPOE) - Continue to sync credentials wirelessly to locks
- DL-Windows - Runs as a background sync service only; nobody uses the GUI for day-to-day operations
- HID ProxCard II credentials - Same card type, same facility code, same reader compatibility
Limitation: DL-Windows remains in the chain as a sync dependency. If the DL-Windows SQL schema changes in a software update, our integration could break. We mitigate this by version-pinning DL-Windows and building schema validation checks.
Plan A: Architecture
Plan B: Full Independence
Eliminate DL-Windows Entirely
Reverse-engineer the Trilogy lock protocol and communicate directly.
DL-Windows communicates with Trilogy locks via a proprietary serial protocol over AL-PCI2-U USB cables (direct) or through Networx gateways (wireless). This protocol is undocumented but can be captured and decoded.
By sniffing the serial traffic between DL-Windows and a test lock, we can map the command structure for add/remove user, assign credential, set schedule, and download audit trail. Once decoded, our platform talks to the locks directly with no middleware dependency.
Additional Work Beyond Plan A
Protocol Reverse Engineering
- Serial capture - Install serial port monitor (Eltima or Portmon) between DL-Windows and a test lock via the AL-PCI2-U cable
- Controlled operations - Perform known add/remove/modify user operations while recording all bytes
- Pattern analysis - Decode command structure, identify start bytes, command types, payload fields, checksums
- Gateway traffic capture - If using Networx, capture TCP traffic between DL-Windows and the gateway to map the network protocol
- Implementation - Build a direct communication module that sends commands to locks via USB cable or gateway
On-site requirement: The serial capture phase requires physical access to a Trilogy lock and the AL-PCI2-U cable. Someone on-site performs the capture (straightforward, scripted steps), and the protocol analysis is done remotely. Estimated 1-2 hours on-site, several days for analysis.
What This Eliminates
Removed Dependencies
- DL-Windows software - Completely removed from the stack. No SQL Server dependency.
- Windows workstation requirement - DL-Windows only runs on Windows. Our platform can run on any OS.
- Schema fragility - No risk of DL-Windows updates breaking our integration.
- Vendor dependency on Napco/Alarm Lock - We own the full communication layer.
Risk: The protocol is proprietary and undocumented. Alarm Lock/Napco does not support third-party integrations with Trilogy locks outside of their partner ecosystem (Lenel, CCURE, Continental Access). If the protocol changes in a lock firmware update, our implementation would need to be re-validated. Napco could also view this as an unsupported use of their hardware.
Plan B: Architecture
Side-by-Side Comparison
SQL Pipeline
DL-Windows as sync engine
- No hardware changes
- Lower technical risk
- DL-Windows remains as dependency
- Windows workstation still required
- Schema coupling to DL-Windows
- All other benefits identical to Plan B
Full Independence
Direct lock communication
- No hardware changes
- Higher technical risk (protocol RE)
- DL-Windows completely eliminated
- Platform-independent (no Windows req)
- No vendor schema dependency
- Requires on-site protocol capture
| Capability | Current State | Plan A | Plan B |
|---|---|---|---|
| Okta Integration | None | Bidirectional SCIM 2.0 | Bidirectional SCIM 2.0 |
| Auto-Provisioning | Manual, 3-15 days | Automated, minutes | Automated, minutes |
| Auto-Deprovisioning | Manual, days-weeks gap | Okta-triggered, immediate | Okta-triggered, immediate |
| Badge ID in Okta | Not tracked | Written to Okta via SCIM | Written to Okta via SCIM |
| Audit Trail | DL-Windows only, manual export | Centralized, queryable, real-time | Centralized, queryable, real-time |
| Badge Design/Print | Separate Bodno workflow | Integrated, template-based | Integrated, template-based |
| DL-Windows Dependency | Primary interface | Background sync only | Eliminated |
| Windows Requirement | Required | Still required for sync | Eliminated |
| Hardware Changes | N/A | None | None |
| Implementation Risk | N/A | Low-Medium | Medium-High |
Cost Breakdown
Current Annual Spend (Estimated)
| Item | Unit Cost | Quantity / Frequency | Annual Cost |
|---|---|---|---|
| HID ProxCard II replacements | $5.78/card | ~200 cards/year (new hires + replacements + lost) | $1,156 |
| Admin labor: badge provisioning/deprovisioning | ~$50/hr | ~45 min per change x 200/year (walking to each lock) | $7,500 |
| Admin labor: DL-Windows management | ~$50/hr | ~2 hrs/week ongoing | $5,200 |
| DL-Windows software | Free | N/A | $0 |
| Lock batteries & maintenance | ~$10/lock | All locks annually | Variable |
| Estimated Annual Operational Cost | ~$13,856+ | ||
Note: These are direct operational costs. The larger value drivers are not dollar savings but operational improvements: faster deprovisioning, cleaner FedRAMP audit evidence, and elimination of manual coordination between disconnected systems.
Proposed Solution: One-Time Investment
| Item | Plan A Cost | Plan B Cost | Notes |
|---|---|---|---|
| Desktop NFC/Prox Encoder (ACR1252U or equivalent) | $50 | $50 | If Bodno lacks built-in encoder module |
| Serial Port Monitor Software | N/A | $0-$100 | Plan B only. Free options available (Portmon). |
| Azure Government Hosting (monthly) | ~$37-$71/mo | ~$37-$71/mo | Azure App Service (B1) + SQL (Basic) + Key Vault + Storage + Monitor. |
| Development effort | Internal | Internal | Built in-house. No external vendor contracts. |
| Hardware changes (locks, readers) | $0 | $0 | Both plans: zero hardware replacement |
Annual Operational Cost (Post-Deployment)
| Item | Current | Proposed | Savings |
|---|---|---|---|
| Badge provisioning labor | $7,500/yr | ~$330/yr | 96% reduction |
| DL-Windows management labor | $5,200/yr | $0-$1,000/yr | 80-100% reduction |
| Cloud hosting | $0 | $444-$852/yr | New cost |
| Card costs | $1,156/yr | $1,156/yr | Same (HID Prox cards retained) |
Net cost analysis: Azure Government hosting adds ~$444-$852/year. Labor savings from automation total ~$12,000/year (walk-to-door provisioning eliminated + DL-Windows management reduced). This means the platform pays for itself many times over in reduced labor alone, with a net annual savings of roughly $11,100-$11,500. The operational and compliance improvements (faster deprovisioning, auditable FedRAMP evidence, Okta integration) come at no additional net cost.
Security Posture Comparison
| Security Control | Current State | Proposed State |
|---|---|---|
| Card credential encryption | None. 125 kHz plaintext broadcast. Cloneable in seconds. | Same (HID Prox retained). Card-level crypto requires reader replacement (future phase). |
| Provisioning authorization | Manual. No enforced approval workflow. | Okta-driven. Automated with configurable approval gates. |
| Deprovisioning speed | Days to weeks. Manual process, no Okta link. | Minutes. Triggered by Okta disable/termination event. |
| Audit trail | Fragmented. DL-Windows local DB + manual exports. | Centralized. Every action logged with timestamps, actor, and context. |
| Data at rest encryption | DL-Windows SQL Server Express. No FIPS-validated encryption. | FedRAMP-authorized cloud with FIPS 140-2/3 validated encryption (KMS). |
| Data in transit encryption | Local only. No TLS for DB access. | TLS 1.2+ with FIPS-validated cipher suites. |
| Access control to management system | Windows login on DL-Windows workstation. | SSO via Okta. Role-based access. MFA enforced. |
| Integration with logical access | Completely disconnected. | Unified through Okta. Physical and logical access managed from one source. |
Note on card-level encryption: Both plans retain HID ProxCard II (125 kHz, unencrypted) because replacing the cards would require replacing the readers in every Trilogy lock. This proposal focuses on the management layer. A future phase could evaluate upgrading to encrypted credentials (MIFARE DESFire EV3 with AES-128) if lock hardware is replaced on its natural refresh cycle.
FedRAMP Alignment
This proposal directly addresses several NIST SP 800-53 Rev 5 control families inherited by our FedRAMP authorization boundary.
PE-3: Physical Access Control
Enforce physical access authorizations at facility entry points. Maintain audit logs. Review physical access devices annually.
How this proposal helps: Automated provisioning/deprovisioning tied to Okta ensures access authorizations are enforced in near-real-time. Centralized audit trail satisfies logging requirements. API-accessible device inventory supports annual review.
SC-13: Cryptographic Protection
Use FIPS 140-validated cryptographic modules for data protection.
How this proposal helps: Credential data stored on Azure Government with FIPS 140-2/3 validated encryption at rest (Azure Key Vault) and in transit (TLS 1.2+). Current DL-Windows SQL Server Express instance has no FIPS-validated encryption.
IA Family: Identification and Authentication
Credential issuance, management, and revocation controls.
How this proposal helps: Full credential lifecycle managed through a single system with Okta as source of truth. Revocation is automated, not manual. Every credential action is attributed to an authenticated user.
AU Family: Audit and Accountability
Generate, protect, and retain audit records.
How this proposal helps: All credential operations generate immutable audit records stored on FedRAMP-authorized infrastructure. Records include timestamp, actor, action, target, and outcome. Queryable and exportable for assessment evidence.
Important distinction: This proposal does not seek FedRAMP authorization for the badge management platform itself. It deploys the platform on FedRAMP-authorized infrastructure and aligns the physical access management process with the control requirements we are already subject to. The goal is to close compliance gaps in our PE, IA, and AU control implementations.
Virtual Infrastructure
The platform will be hosted on Azure Government, consistent with our existing FedRAMP authorization boundary. This avoids adding a new CSP to our boundary documentation and inherits controls already assessed.
| Component | Azure Service | Estimated Monthly Cost |
|---|---|---|
| Application hosting | Azure App Service (B1: 1 core, 1.75GB) | ~$15 - $30 |
| Database | Azure SQL Database (S0: 10 DTUs, 250GB) | ~$15 - $25 |
| Key management & encryption | Azure Key Vault (Standard) | ~$1 - $3 |
| Blob storage (photos, templates) | Azure Blob Storage (Hot, ~5-10GB for photos) | ~$1 - $3 |
| Monitoring & logging | Azure Monitor + Log Analytics | ~$5 - $10 |
| Estimated Total Monthly | ~$37 - $71 | |
Why so low? This is a low-traffic internal tool managing ~1,000 badge records. The data volume is small (user records, credential assignments, audit logs). Badge photos are stored in Blob Storage at pennies per GB. The smallest Azure tiers handle this workload comfortably.
Azure Government is FedRAMP High authorized (DoD IL4-6). All data at rest is encrypted via FIPS 140-2/3 validated modules through Azure Key Vault. All data in transit uses TLS 1.2+ with FIPS-validated cipher suites. These are inherited controls we already leverage.
Frontend Access Security
Badge administrators will reach the platform from the corporate network, which means traffic crosses from our commercial environment into Azure Government. A common question: does this require a VPN, ExpressRoute, or private peering? For a FedRAMP Moderate workload of this size, the answer is no. The standard control set below satisfies SC-7 (boundary protection), SC-8 (transmission confidentiality), SC-13 (cryptographic protection), and IA-2(1) (MFA for privileged accounts).
Transport Layer
- TLS 1.2 or 1.3 only, enforced at the Azure App Service front door. TLS 1.0 and 1.1 disabled.
- FIPS 140-2/3 validated cipher suites. Inherited from the Azure Government baseline, documented in our SSP.
- HSTS header with a minimum one-year max-age to prevent protocol downgrade.
Authentication & Authorization
- Okta SSO is the only sign-in path. No local accounts, no password-based auth.
- MFA enforced at the Okta policy level for every session touching the badge platform. FIDO2 or Okta Verify push, no SMS.
- Role-based access scoped via Okta groups. Badge admin, auditor, and read-only roles map to distinct group memberships.
- Session timeout of 15 minutes idle, 8 hours absolute, to align with AC-12.
Conditional Access
- Managed device posture check. Only corporate-managed endpoints can reach the app. Personal devices are blocked at the identity layer.
- IP allowlist for privileged roles. Badge admins and auditors sign in from the corporate network or a sanctioned VPN egress range. Read-only roles can be opened up if needed.
- Geo-fencing. Sign-in blocked outside the US to reduce the attack surface.
When a Private Network Path Would Be Required
If this workload were classified FedRAMP High, DoD IL4, or IL5, we would need ExpressRoute or an Azure Government private endpoint to keep admin traffic off the public internet entirely. That is not the case here. The data classification is Moderate: employee PII, badge photos, credential numbers, and audit logs. TLS plus SSO plus conditional access is the standard and sufficient control set.
Bottom line: admins sign in through Okta over HTTPS from a managed corporate device. The connection is encrypted, the identity is verified, and the device is trusted. No new network plumbing is required, and the control evidence maps cleanly to the FedRAMP controls we already report against.
Recommendation
Start with Plan A. Pursue Plan B as a follow-on phase.
Plan A delivers 95% of the operational and compliance value in 12 weeks with significantly lower technical risk. The bidirectional Okta SCIM integration, automated provisioning/deprovisioning, Badge ID visibility in Okta, centralized audit trail, and FedRAMP-aligned infrastructure are all delivered in Plan A.
The remaining 5% (eliminating DL-Windows entirely) can be pursued as Plan B once Plan A is operational and proven. The protocol capture and reverse engineering work is additive, not a rewrite. Plan A's platform architecture is designed to swap the DL-Windows SQL sync module for a direct communication module with no changes to the rest of the system.
Why Not Start with Plan B?
Risk vs. Value
Protocol reverse engineering introduces uncertainty. The serial protocol may be straightforward, or it may involve complex state machines, firmware-version-specific behavior, or undocumented edge cases. Starting with Plan B means the highest-risk work blocks all other value delivery.
With Plan A, we deliver working value in 12 weeks and de-risk Plan B by running both approaches in parallel if desired.
Future Roadmap
Phase 1: Plan A (This Proposal)
Custom platform with DL-Windows SQL pipeline. Bidirectional Okta SCIM, badge management, FedRAMP-aligned infrastructure.
Phase 2: Plan B (Optional, Follow-On)
Protocol reverse engineering. Direct lock communication. Eliminate DL-Windows entirely.
Phase 3: Credential Upgrade (Future, On Lock Refresh Cycle)
When Trilogy locks reach end-of-life and are replaced, evaluate upgrading to MIFARE DESFire EV3 with AES-128 encryption. This eliminates the card-cloning vulnerability. No additional cost if timed with natural hardware refresh.
Cutover & Reconciliation
Existing cardholders already live in the DL-Windows SQL database. We are not importing them from scratch. What we do need is a one-time reconciliation so the new platform, Okta, and DL-Windows agree on who holds which badge on day one.
Step 1: Snapshot the DL-Windows Database
Take a read-only export of the current user and credential tables before any writes occur. This becomes the source of truth for the reconciliation pass and the rollback point if anything goes sideways.
Step 2: Match DL-Windows Records to Okta Identities
Run an identity reconciliation job that matches each DL-Windows cardholder to an Okta user. Primary match on email, secondary on normalized full name plus department. Anything that does not match cleanly goes into a review queue for a human to resolve before cutover.
- Clean match - email or name plus department aligns with exactly one active Okta user. Auto-link.
- Ambiguous match - multiple candidates or partial match. Flag for admin review.
- No match - DL-Windows record has no Okta counterpart. Classify as contractor, service account, stale entry, or data error.
Step 3: Backfill Badge IDs into Okta
For every clean match, write the existing Badge ID to the custom Okta attribute defined during SCIM design. This makes the Okta directory reflect current physical access from day one, so the audit trail and deprovisioning automation work for existing staff, not just new hires.
Step 4: Resolve Orphans
Two orphan classes need an owner and a disposition before cutover:
- DL-Windows entries with no Okta user - common causes: departed employees whose badges were never removed, long-term contractors not in Okta, legacy test entries. Each one is either deactivated in DL-Windows, linked to a newly created Okta contractor account, or documented as an approved exception.
- Okta users with no badge - expected for remote staff and new hires who have not been badged yet. No action required, but the list confirms the system knows who is eligible for future provisioning.
Step 5: Dual-Write Validation Period
For the first two weeks after cutover, the new platform writes to both DL-Windows and its own audit store for every provisioning event. A nightly diff job confirms the two systems stay in sync. Once the diff runs clean for five consecutive days, DL-Windows drops to sync-engine-only and the new platform becomes the system of record.
What this buys us: zero disruption to existing cardholders, a verified mapping of every active badge to an Okta identity, and full automation for day-one deprovisioning events. The reconciliation is a one-time investment that makes every subsequent audit, termination, and access review dramatically faster.
Next Steps
Immediate Actions (If Approved)
- Switch card supplier - Replace Farpointe Data PSC-1-H ($5.78/card) with equivalent 26-bit Wiegand cards from a lower-cost supplier (~$2.40/card). Immediate savings, zero risk.
- Deploy Networx gateways - Procure 2-4 AL-IMEPOE gateways ($600-$2,000), configure on a dedicated VLAN with port 10001 only. Eliminates walk-to-door workflow immediately and is required for both Plan A and Plan B.
- Confirm Bodno printer model - Determine if it has a built-in prox encoder module. If not, procure a standalone encoder (~$50).
- Identify facility code - Look up the facility code and card number range in DL-Windows to ensure new cards use the correct scheme.
- Connect to DL-Windows SQL Server - Verify database access and begin schema mapping. This validates Plan A feasibility with zero risk.
- Provision Azure Government resources - App Service, Azure SQL, Key Vault within our existing tenant.
- Begin Okta SCIM integration design - Define which Okta user attributes map to badge fields, and which custom attribute will hold the Badge ID for write-back.
The first three actions cost nothing and take less than a day. They validate the core technical assumptions of Plan A before any development investment. If the DL-Windows database schema is more complex or locked down than expected, we will know immediately and can adjust the approach.