Identitätsprüfung für Online-Prüfungen: ein praktischer Leitfaden

Identity verification for online exams confirms that the registered candidate is the person beginning and completing an assessment. It can combine account authentication, document checks, facial comparison, liveness detection, and human review, depending on the exam’s risk level. For universities, certification bodies, corporate learning teams, and public-sector organizations, the challenge is balancing reliable checks with privacy, accessibility, and a process candidates can complete without unnecessary friction.

Key takeaways

• Identity verification should match the consequence of the exam rather than applying the strongest available check to every assessment
• Common methods include account authentication, photo ID checks, facial comparison, liveness detection, and human review
• A failed automated check should lead to a clear fallback process, not an automatic rejection or misconduct decision
• Procurement teams should assess privacy, biometric-data handling, retention, accessibility, LMS integration, and peak-volume performance
• Verification works best when it connects with proctoring, assessment, authentication, and reporting rather than operating as another point solution

• Institutions should test the complete candidate journey across different devices, documents, locations, and accommodation needs before scaling

   

Why identity verification matters in online assessment

Remote assessment removes the physical checkpoint of an invigilator comparing a candidate with a student card or attendance list. Identity checks create a clearer link between the candidate record, the assessment session, and the result.

The level of assurance should reflect what the result is used for. A short quiz may only need secure account access, while a final examination or professional certification may justify document verification and additional checks. Teams asking how online proctoring works should begin by defining the identity risk, acceptable evidence, and who decides uncertain cases.

How identity verification for online exams works

Most systems follow the same core stages. A good process tells candidates what is required before exam day and provides a clear route when automation cannot confirm identity.

Account authentication

The candidate signs in through an LMS, assessment platform, SSO service, or exam portal. This connects the session with an institutional record, although a login alone may not be enough for a high-stakes exam.

Device and permission checks

The system checks the camera, microphone, browser, permissions, additional displays, prohibited applications, and supported device settings.

Document capture

The candidate presents an approved document, such as a student card, passport, or national identity document. The platform may check image quality, expiry details, and whether the document is accepted.

Facial comparison and liveness checks

A live image can be compared with the photograph on the document or an approved record. Liveness controls aim to distinguish a present person from a photograph or replayed video, although no control is infallible.

Decision and fallback review

The system records whether the check passed, failed, or needs review. A trained reviewer can assess unclear images, name differences, document problems, or accessibility needs.

Identity checks may sit within a wider automated or human-supervised process. Readers asking what AI proctoring is should distinguish between confirming who the candidate is and monitoring what happens during the assessment. The functions can work together, but they need separate rules.

Core features to look for

Strong identity verification for online exams should support more than a facial match. It should give your team control over methods, exceptions, audit records, and the candidate experience.

Core features to evaluate include:

• Flexible verification methods: Support for institutional login, photo ID, facial comparison, liveness checks, and human review
• Configurable exam rules: Different identity requirements for low-, medium-, and high-stakes assessments
• Document support: Clear lists of accepted documents, image-quality guidance, and review routes for unusual cases
• Fallback workflows: Manual review or alternative verification when automation cannot reach a confident result
• Accessibility support: Processes that account for assistive technology, facial differences, limited mobility, religious dress, and other legitimate needs
• Audit records: Timestamps, verification results, reviewer actions, and evidence needed for institutional review
• Role-based access: Controls that limit sensitive identity information to authorised staff
• Integration options: LMS, LTI, API, SSO, assessment, and reporting connections that reduce duplicate data entry
• Candidate guidance: Practice checks, device instructions, privacy notices, and clear support routes

When comparing online proctoring software, ask vendors to demonstrate the full journey. Test a successful check, a poor-quality document, a failed comparison, an accommodation, and a case that needs human review.

Balancing security with privacy and compliance

Identity verification may involve names, document images, facial photographs, biometric templates, device data, and verification outcomes. Your institution should know what is collected, why it is needed, where it is processed, who can access it, and when it is deleted. More data does not automatically mean more security.

GDPR compliance may require a lawful basis, clear notices, data minimization, access controls, defined retention, and additional safeguards for biometric data. Other jurisdictions may impose consent, disclosure, or deletion duties, so privacy and legal teams should be involved early. Wider discussions about AI in higher education also make transparency important: candidates should know which checks are automated and whether a person reviews consequential decisions.

A practical privacy review should cover:

• The minimum data required for each exam type
• Whether raw images, recordings, or biometric templates are stored
• Hosting location and data sovereignty requirements
• Retention and deletion schedules
• Vendor and subprocessor access
• Encryption and role-based permissions
• Candidate access, correction, complaint, and appeal routes
• Alternative processes where local law or individual circumstances require them

A proportionate process can provide suitable assurance while limiting data collection and explaining how information is handled.

Scalability for growing programs

A workflow that works for 50 candidates may fail when thousands begin within the same hour. At scale, consider verification queues, processing time, reviewer capacity, support coverage, resits, and regional demand. Peak performance matters more than an average response time.

Scalability also depends on operations. If every uncertain result requires one central administrator, review queues can become a bottleneck. Define which cases can proceed, need immediate review, or can be checked after the exam.

Before rollout, test:

• Concurrent candidate starts
• Different document types and languages
• Low-bandwidth connections and older devices
• Poor lighting or camera quality
• Name and record mismatches
• Accessibility and accommodation scenarios
• Human-review turnaround times
• Support demand during peak windows

Central teams can define privacy, security, and audit standards while departments configure exam-specific rules. This supports consistency without forcing every assessment into one model.

How to evaluate vendors

Vendor evaluation should begin with your exam types, candidate groups, legal obligations, and current systems. Understanding how online proctoring works helps you test where verification begins, what data moves, and how results reach administrators.

Ask for evidence behind accuracy, liveness, and scalability claims rather than accepting headline percentages. Useful evidence explains the test population, conditions, thresholds, error rates, and review method. Your pilot should use realistic candidates and devices.

Also confirm who configures the system, migrates data, trains staff, writes candidate communications, manages appeals, and supports exam-day incidents. The vendor should be clear about its responsibilities and yours.

Common pitfalls

Projects often fail because teams focus on the strongest technology instead of the complete assessment process. Common mistakes include:

• Using the same checks for every exam: Applying high-stakes verification to low-risk assessments can create unnecessary cost, delay, and privacy concerns.
• Treating an automated failure as a final decision: Poor lighting, camera quality, document wear, name differences, or accessibility needs can prevent a valid candidate from passing an automated check.
• Ignoring candidate communication: Students need to know which documents are accepted, what data is collected, how to prepare their device, and where to get help.
• Testing only ideal conditions: A controlled vendor demonstration does not show how the system performs with older devices, weak connections, unusual documents, or peak exam traffic.
• Adding another disconnected tool: A verification product that does not connect with your LMS, assessment platform, authentication, and review process may increase manual administration.
• Keeping data without a clear purpose: Undefined retention creates privacy and security risk. Each data type should have an owner, purpose, retention period, and deletion process.
• Failing to plan appeals and exceptions: Candidates need a fair route to challenge an incorrect result or complete an alternative check.

A wider proctoring guide can help teams map verification into the full exam journey. Identity assurance is strongest when checks, monitoring, review, and decisions follow one documented process.

Constructor Proctor's approach to identity verification

Constructor Proctor supports identity verification alongside AI proctoring, live proctoring, secure-browser controls, and exam-security workflows. Institutions can use different oversight levels based on exam risk, while LMS connections and APIs help keep candidate and assessment data closer to existing systems. This helps organizations reduce fragmented tools rather than add another point solution.

As part of Constructor Tech’s all-in-one platform, Proctor sits within an integrated ecosystem built for education and research. It connects with assessment, learning, scheduling, data, and analytics, while Constructor University in Bremen provides an institutional environment for product testing and feedback. Buyers should still validate identity methods, privacy, accessibility, integrations, review workflows, and regional requirements before deployment.

A practical evaluation of Constructor Proctor should include:

• The identity methods available for each proctoring mode
• Candidate and administrator workflows
• Manual-review and exception handling
• Secure-browser and device controls
• LMS, LTI, SSO, and API requirements
• Retention, hosting, and data sovereignty settings
• Support during implementation and peak exams

The aim is a secure, scalable, and reliable process that provides suitable assurance without making the candidate journey harder than necessary.