Device IAM · Architecture case study
Device identity & trust across the full lifecycle
A connected device needs a durable identity, a current owner, and an explicit basis for access—through installation, everyday use, transfer, and retirement.
- Project context
- Connected-device identity and access management
- My role
- Solution Architect & Principal .NET Engineer
- Focus
- Control-plane design, device security & multi-tenancy
01 / The challenge
Network access is only the beginning.
Device platforms often begin with shared secrets, manual ownership records, and permissions spread across several applications. Those choices become difficult to manage when credentials expire, technicians need temporary access, or a device changes customers.
The architectural objective was a shared identity and trust layer that existing products could adopt incrementally, while keeping product-specific applications separate from device-security concerns.
02 / Platform architecture
A shared control plane.
Explicit responsibilities.
Device identity, credentials, policy, ownership, risk, and audit form distinct parts of the design.
Onboarding
Claims, enrollment, activation
Identity registry
Device records and lifecycle
Credential service
Certificates, keys, rotation
Policy engine
Access and trust decisions
Ownership
Assignment and transfer
Risk engine
Signals, posture and scoring
Audit service
Security events and evidence
Integration API
Webhooks, SDKs and adapters
03 / Architectural reasoning
The boundaries that matter.
Each boundary addresses a lifecycle problem and brings its own engineering responsibilities.
Separate device identity from its credential.
A durable device record can remain meaningful while a certificate or signed credential expires, rotates, or is revoked.
Engineering consideration Issuance, expiry, revocation, and recovery need an explicit lifecycle of their own.
Treat ownership transfer as a security event.
The device persists, but the customer relationship changes. The transfer flow must revoke the prior relationship and establish the new tenant's authority.
Engineering consideration Permissions and ownership records must agree throughout the handover, including failure and recovery paths.
Make authorization depend on context.
A credential is one input. The design also considers the tenant, requested operation, device state, technician support window, and risk signals.
Engineering consideration Policy evaluation needs trustworthy context and a defined response when required evidence is missing or stale.
Keep trust concerns outside product applications.
A common control plane gives device products a consistent place to integrate identity, policy, and lifecycle events.
Engineering consideration A shared trust service becomes a critical dependency; integration design must account for availability and failure behavior.
04 / Designed lifecycle
Trust continues after onboarding.
The lifecycle connects the initial claim to later access decisions, credential changes, transfer, and retirement.
Register
Create the device record, model, manufacturer details, and ownership claim.
Onboard
Verify an enrollment token, bootstrap credential, or attestation evidence.
Issue identity
Establish a unique device identity and scoped credential.
Authorize
Evaluate device, tenant, user, and resource context against policy.
Monitor
Observe health, credential age, anomalies, and risk signals.
Rotate
Renew credentials before expiry or following a security event.
Transfer
Revoke the prior ownership relationship and establish the new one.
Retire
Disable access, revoke credentials, and retain the audit history.
The case study defines this lifecycle and describes an onboarding prototype. Certificate rotation and risk scoring are identified as planned capabilities.
05 / Identity, authorization & risk
A credential starts the decision.
Access depends on the relationship between identity evidence, ownership, the requested operation, and policy.
Identity & credentials
- Unique device identifier
- Certificate or signed credential
- Issuer, expiry, and revocation
- Device model and firmware metadata
Policy & access
- Tenant and ownership context
- Resource and operation requested
- Device lifecycle state
- Technician role and support window
Risk & audit
- Health and failure signals
- Unexpected behavior or location
- Ownership or configuration changes
- Risk, quarantine, and event history
A registered camera may upload telemetry when its certificate is valid, it belongs to the active tenant, its risk is below the configured threshold, and the requested API scope is permitted.
Decision: allow, deny, or require additional verification.06 / Integration design
Meet existing products
where they are.
Four integration patterns accommodate different device capabilities and existing cloud investments.
Direct device API
A capable device calls onboarding and token endpoints over TLS.
Trusted gateway
A gateway represents constrained devices and carries their identity into the platform.
Vendor cloud adapter
An existing product cloud synchronizes identities, ownership changes, and risk events.
SDK or middleware
An application validates device tokens and requests policy decisions through an integration layer.
Target scenarios: smart buildings, CCTV, industrial equipment, healthcare devices, consumer IoT, and fleet systems.
07 / My contribution
Architecture through engineering.
I defined the control-plane architecture, device and ownership models, authorization boundaries, lifecycle flows, and integration patterns.
Implemented foundation
.NET services & APIs
Implemented services and APIs, applied clean architecture and domain-driven design, developed tenant-aware data access, and integrated audit and lifecycle event handling.
Prototyped workflow
Device onboarding
Prototyped onboarding workflows and designed the authentication and authorization flows that connect device identity to application access.
Product direction
Lifecycle capabilities
Defined ownership transfer and technician-access controls as key capabilities, with certificate rotation and risk scoring planned as further work.
.NET · ASP.NET Core · REST APIs · OAuth 2.0 / OpenID Connect concepts · X.509 / PKI · PostgreSQL · Multi-tenant SaaS · Policy-based authorization · Audit logging