Risk assessment integration
Pillar 1 of 25 · 7 min read · Grounded in l hybrid identity architecture research — IBM, NVIDIA, HYPR & Ciptor
See how this applies to your environment
Book a 30-minute briefing with Ciptor. We'll walk through what live-fire validation typically uncovers in environments like yours.
The assumption
A clean annual penetration test means our identity posture is under control
Most organisations measure their security posture with instruments calibrated to the past. Annual penetration tests, quarterly vulnerability scans, biannual compliance audits — all tell you what your environment looked like at a fixed point in time. The security team completes the assessment, files the report, closes the findings, and returns to operations with a reasonable degree of confidence. The next scheduled assessment is twelve months away. Nothing in the methodology requires checking what happens in between.
The reality
Identity risk is continuous and dynamic. The gap between your last assessment and today is where most incidents actually begin.
Point-in-time assessments capture a snapshot of entitlement state, authentication configuration, and access policy compliance on the day the assessors were present. The environment did not stop changing when they left. Permissions accumulate as users change roles and retain access to previous systems. Contractors are not deprovisioned on their last day. Service accounts proliferate across application stacks. Authentication configurations drift when patches are applied or integrations are modified. Access drifts — silently, legitimately, between assessment cycles — and none of it generates an alert.
59% Of organisations increased their security budget as the most common response to a breach — meaning almost 60% discovered their posture problem after the incident, not before it. Source: HYPR / S&P Global — State of Passwordless Identity Assurance 2026
Identity drift is the gradual accumulation of access entitlements, credential states, and authentication configurations that diverge from policy over time. It is not caused by attacks — it is caused by normal operations. A user who changes roles retains access to their previous systems. A contractor's account is not deprovisioned on their last day. An application gets configured with a service account that shares credentials with three other systems. Each of these creates an attack window. None triggers a security alert, because from a technical perspective they are all legitimate access events — they simply reflect a state that should not exist.
43% Of passwordless adoption deployments are limited to specific user personas — primarily executives and privileged IT staff — leaving the majority of the workforce outside the scope of continuous identity assurance controls. Source: HYPR / S&P Global — State of Passwordless Identity Assurance 2026.
"In the majority of incident investigations we conduct, the initial access vector was not a novel exploit or a zero-day. It was a credential or entitlement that should have been removed months earlier but wasn't. The posture gap is almost never technical — it's operational." — Syndis incident response operations synthesis, 2025.
The fragmented ownership of identity security compounds the problem. In most organisations, provisioning is managed by HR, access control by IT, privileged access by the security team, and application permissions by individual development teams. Without a unified identity governance layer, no single team has visibility into the complete access state of any given user — let alone the ability to detect when it drifts from policy.
The blueprint
Replace point-in-time assessment with continuous identity risk monitoring — and instrument the employee lifecycle so entitlement state changes in real time, not at the next scheduled review.
The objective is not to eliminate periodic assessments — they remain valuable for structured third-party verification and regulatory compliance. The objective is to ensure that the environment between assessments is continuously monitored, and that drift from policy is detected and remediated before it generates attack surface. The two capabilities required are continuous entitlement visibility and automated lifecycle instrumentation.
Continuous entitlement visibility
Identity governance tooling that surfaces access entitlement state in real time is the foundational requirement. Every user's access footprint — which systems they can reach, which privileges they hold, which authentication methods are active for their accounts — should be visible and queryable at any moment, not reconstructed from logs during an incident investigation.
The practical implementation involves integrating your identity provider (Azure AD, Okta, Active Directory) with an identity governance platform that maintains a live graph of user-to-access relationships. This graph is the source of truth for entitlement state. Deviations from baseline — a user who gains access to a system outside their role profile, a service account that acquires new permissions, a privileged account that goes unreviewed for more than 30 days — generate automated alerts rather than waiting for the next quarterly review.
This is distinct from SIEM-based detection, which monitors authentication events. Entitlement monitoring monitors the rights themselves — before they are exercised. Catching an overprivileged account before it is used is categorically more effective than detecting anomalous behaviour after the attacker has already accessed the resource.
Automated employee lifecycle instrumentation
Provisioning and deprovisioning must be automated events triggered by HR system signals, not manual processes completed via IT tickets. The implementation pattern is straightforward: HR system (Workday, SuccessFactors, or equivalent) emits a lifecycle event — new hire, role change, termination, leave of absence — and that event triggers automated entitlement changes in the identity provider within a defined SLA. A user who leaves on Friday has their access state changed that afternoon. A user who changes roles on Monday has their previous system access reviewed and removed by Tuesday.
The specific SLA targets vary by role sensitivity, but the principle is consistent: no manual intervention in the critical path between lifecycle event and entitlement change. Every step that requires a human to process a ticket introduces delay that creates attack surface. The contractor who was not deprovisioned for three weeks is not a people problem — it is a process architecture problem.
Baselining and drift detection
Continuous monitoring requires a baseline to detect drift against. Define the expected access state for each role and user type — which systems, which privilege levels, which authentication methods. When a user's actual entitlements diverge from that baseline, the alert should fire on the divergence itself, not on subsequent suspicious activity. The goal is to catch the drift that creates opportunity before an attacker identifies and exploits it.
Baseline definition does not require a perfect role model from day one. A pragmatic starting point is to baseline the current entitlement state of each role — accepting that some entitlements may already be excessive — and alert on any further divergence while running a parallel access certification campaign to clean up the existing state. This is more operationally achievable than attempting to define a perfect role model before beginning monitoring.
The hardware credential layer
Governance tooling closes the entitlement drift gap. But there is one class of credential that eliminates the credential risk entirely, regardless of what governance layer sits above it — the hardware security key. When authentication is anchored in a physical device with asymmetric cryptography, there is no password to harvest, no session to hijack, and no hash to replay. The drift that matters most — credential exposure — disappears at the hardware level, making it unavailable as an attack path regardless of what the entitlement state looks like.
Not all hardware keys deliver the same assurance. Two questions determine whether a key matches a given deployment context:
Question |
What it determines |
| Who manufactured the chip and where? | Supply chain sovereignty and nation-state risk exposure |
| Does it support biometric verification on-device? | Whether PIN sharing and physical key handover remain a residual risk |
Two keys — for different deployment contexts
NeoWave (ANSSI-certified, CC EAL6+, EU sovereign supply chain)
French-engineered and ANSSI Security Visa certified — the only EU-sovereign hardware authentication standard that formally validates the supply chain, not just the protocol. CC EAL6+ secure element. The relevant context: regulated industries, defence supply chains, and environments where the manufacturer's national jurisdiction is a material procurement consideration. No biometric sensor — authentication is PIN-bound to the device, not biometric-bound to the user.
Feitian BioPass K49 (CC EAL6+, on-device fingerprint, PQC-ready)
Built on the FT-JCOS secure element certified to CC EAL6+. The K49 adds on-device biometric verification: the fingerprint template never leaves the chip, authentication is user-bound rather than device-bound, and PIN-sharing or physical key handover ceases to be a residual risk. PQC-ready via dedicated ML-KEM/ML-DSA hardware co-processor. The relevant context: workforce-scale deployment where usability and biometric binding matter as much as cryptographic depth.
Both keys are available through Ciptor. The right choice depends on your deployment context, regulatory environment, and risk profile. If you're evaluating both, the free passwordless audit is the right place to work through the decision.
Sequencing the continuous monitoring deployment
Step 1: Inventory your current entitlement state. Before you can detect drift, you need a baseline. Pull a complete user-to-access map from your identity provider — this is often more revealing than the periodic assessment, because it reflects the actual current state rather than a structured review.
Step 2: Integrate your HR system with your identity provider so lifecycle events trigger automated entitlement changes. Start with terminations — this is the highest-risk gap and the easiest workflow to automate.
Step 3: Define role-based baselines for your highest-risk user populations: administrators, privileged users, users with access to financial systems or sensitive data. Alert on divergence from baseline for these groups first.
Step 4: Run an access certification campaign against the full user base to clean up excess entitlements accumulated over time. This is a one-time remediation step, not a recurring process — recurring access reviews are what the continuous monitoring replaces.
Step 5: Extend hardware credential deployment from privileged users to the broader workforce, removing password-based authentication as an option where continuous monitoring confirms clean entitlement state.
