Remote-first work and artificial intelligence have made it easier for attackers to pretend to be someone they are not. The threat is no longer limited to stealing an employee’s credentials. An attacker can impersonate an employee. A recent Wall Street Journal investigation shows what this looks like in practice: North Korean operatives using stolen identities, artificial intelligence, and U.S.-based accomplices to obtain remote jobs at American companies. According to the investigation, one team infiltrated eight companies in only a few months.
A separate Justice Department case illustrates how the deception can continue after hiring. A U.S.-based facilitator appeared in an online interview and showed his own driver’s license and U.S. passport. After he was hired, an overseas worker believed to be a North Korean national used his credentials and remotely accessed the company-issued laptop to perform the work. The facilitator used similar misrepresentations to obtain employment from at least 13 U.S. companies.
These cases expose more than a weakness in hiring or background checks. They expose a continuity-of-identity problem. The person who completes the interview, passes an initial identity check, or receives approval for access might not be the person who uses the account later.
The gap between authentication and identity
Authentication confirms that a user can present an approved credential or factor, such as a password, passkey, multifactor authentication method, or managed device. These controls verify the credential or device, but they themselves do not verify that the person using it is the person the account was issued to. A credential can be shared. An approved laptop can be controlled remotely. A facilitator can appear during an interview and then hand the account to someone else.
FBI has recommended that organizations implement identity-verification processes during interviewing, onboarding, and throughout the employment of remote workers. The phrase “throughout employment” is important. Identity cannot be treated only as a fact established on a worker’s first day. Oracle Cloud Infrastructure (OCI) Identity Access Management (IAM) Identity Assurance is designed to add a “verified human” signal to existing IAM controls. It establishes an initial connection between a digital identity and a real person, then verifies that connection again over time.
The process begins with identity verification. A supported third-party identity-verification provider validates a government-issued identity document and compares a live video selfie with the photograph on that document, creating an initial trust anchor for the user. User then enrolls in facial biometrics. OCI IAM converts facial characteristics into an encrypted mathematical representation, or a biometric embedding, for future comparisons. Raw facial images are not stored. Active and passive liveness checks help establish that the system is interacting with a live person rather than a photograph, recording, or other presentation attack.
After enrollment, an Identity Assurance policy will require the user to complete facial biometric verification at regular intervals. The live video selfie is compared with the enrolled representation, and the result is recorded in OCI Audit for monitoring and investigation. This recurring verification is what makes Identity Assurance relevant to remote-worker threats. It does not only ask whether the user passed an identity check when the account was created. It produces evidence about whether the person behind the account continues to match the person who established the identity. We announced general availability of this capability earlier this year. Oracle also uses identity and biometric verification as part of controls designed to help protect Oracle assets.
Put Identity Assurance signals to work today
Customers can use Identity Assurance evidence today to support analysis of risk signals associated with their users. Because OCI IAM, Identity Assurance, and OCI Audit are part of the same cloud stack, a biometric verification outcome can be evaluated with the authentication and access context that explains it – what access does the user have, what activity occurred around the verification event, and which signals caused the user to be classified as a higher risk.
OCI Audit is the common evidence layer. Identity Domain events can include user login and application-access activity, along with the user, authentication factor, client IP address, platform, protected resource, Identity Assurance enrollment or verification outcome, and timestamp. Because the evidence is exposed through OCI Audit, customers can use the Identity Assurance signals directly, or integrate them into security information and event management, user and entity behavior analytics, and other security analytics systems.
A Cloud Guard-style Identity Assurance monitoring interface is shown below as a conceptual example of how this evidence could be presented and analyzed. The first view illustrates ranking users by risk tier and showing signal distribution across a monitored population. The second view illustrates how an analyst could select a user and see the events, context, and rules that contributed to the risk level. This type of approach could help an analyst to move from “this user is high risk” to “these specific events and access conditions caused the user to be ranked high risk.”
In the prototype shown above, the dashboard illustrates how a system could aggregate each user’s verification history across a defined monitoring window and scores three customer-facing signal categories: passive-liveness failures, active-liveness failures, and environment or setup issues. It then weighs those categories, adjusts priority when the same signals recur across multiple days or are reinforced by context deviations and corroborated model signals, such as IP address changes or device trust deviations. Explicit thresholds place users into low, elevated, or high tiers, with high-tier users promoted into the review queue. The drill-down preserves the contributing signal counts, persistence, contextual factors, and event history so analysts can understand why each user was prioritized rather than relying on an unexplained score. Customers can adjust the signals, weights, and thresholds to match their environment and risk tolerance.
The same operating logic could be applied conceptually to three agent roles while keeping the evidence and decision path visible to analysts.
Signal-capture agent. A signal-capture agent could collect high-signal Identity Assurance outcomes and the related login, application-access, device, network, and resource context from OCI Audit. It should capture only the evidence needed to answer a defined investigation question rather than treating every event as equally important. For example, an unsuccessful liveness check may justify review, while a selfie mismatch may justify a higher priority.
Triage agent. A triage agent could aggregate the evidence over time, apply customer-defined rules, add access and business context, and increase or decrease confidence based on persistence and corroboration. The same verification outcome can therefore lead to different priorities for a low-access user and a production administrator. The agent should preserve the rules and evidence behind the result so analysts can tune noisy signals and understand each recommendation.
Remediation agent. A remediation agent could use the triage result into a policy-approved next step, such as requesting another verification, notifying an analyst or manager, reducing access, or opening an incident. The agent should recommend or initiate only the actions the customer has authorized, with human review for higher-impact decisions.
This operating model is more useful than treating every event as an isolated alert. It helps the analyst understand what happened, why it matters, and what evidence supports the next action. Identity Assurance is also a defense-in-depth control. It does not replace hiring diligence, staffing-provider controls, endpoint security, least privilege, access reviews, or behavioral monitoring. It adds evidence those controls might not otherwise provide: whether the person using the account matches the person who established the identity.
Make identity a continuing security signal
North Korean remote-worker schemes show why identity cannot remain a one-time onboarding fact. A person can pass an interview, present legitimate identity documents, receive an approved device, and still transfer the work and access to someone else. Authentication helps establish that an approved account, factor, or device is being used. Identity Assurance adds evidence about the human being behind that access. OCI Audit makes that evidence available for monitoring and investigation.
The greatest security value can come from operationalizing the signal. By combining Identity Assurance outcomes with access and contextual data, customers can use those signals as additional inputs when prioritizing users for review and provide analysts with additional evidence for investigation and response.
Learn more