Why don’t you always share information about vulnerabilities or bypasses?
A reasonable question.
With traditional software, openness about a resolved security flaw often leads to a safer product. With anti-cheat software, it works fundamentally differently.
That is why we are cautious about sharing information on bypass methods, whether it concerns theoretical scenarios, current vulnerabilities, or methods from the past that have since been resolved.
In this article, we explain why, how we develop and maintain our anti-cheat security, and how we collaborate with educational institutions in this regard.
Anti-cheat is a continuous cat-and-mouse game
In regular cybersecurity, an attacker tries to gain access to a system over which they have no control. Think of a hacker attempting to break into a server.
With digital exams on personal devices (BYOD), the situation is exactly the opposite. The student is the administrator of the laptop on which our software runs. So, our security operates on the device of the person who might be trying to cheat.
This means that cheating on a BYOD device can never be made completely impossible. The strength of anti-cheat lies in continuously raising the bar: making cheating increasingly difficult, blocking new techniques as quickly as possible, and constantly responding to evolving attack methods.
On managed devices, where students do not have administrator rights, this risk is significantly smaller. Nevertheless, even there, any publicly disclosed description of a bypass method or the security mechanisms we use immediately provides actionable leads for new variants.
A discovered vulnerability is therefore not automatically “safe” to publish after a fix. A solution removes the original method, but the knowledge about the underlying workings remains valuable for anyone seeking new ways to circumvent the same security.
Anti-cheat is thus not a product you build once and then it is “done”. It is a continuous cat-and-mouse game in which attackers and defenders constantly adapt.
Prevention instead of detection afterwards
Safe Exam Workspace is designed to prevent exam fraud as much as possible, not to detect it afterwards.
This fundamentally distinguishes our approach from remote proctoring solutions. Whereas proctoring software monitors students via, for example, webcam footage, screen recordings, or behavioural analysis, Safe Exam Workspace focuses on preventing unauthorised tools from being used during an exam in the first place.
We believe prevention is more reliable than interpretation afterwards. A student who cannot access unauthorised resources cannot use them during the exam.
Moreover, this approach is more privacy-friendly. No webcam recordings, behavioural analyses, or AI assessments are needed to create a secure exam environment.
How we continuously improve our anti-cheat
Effective anti-cheat requires ongoing development. New techniques constantly emerge, and our security evolves accordingly.
Therefore, we invest in, among other things:
- annual independent penetration tests conducted by specialised external security parties;
- in-house research into new attack techniques;
- monitoring of public and commercial communities where new cheats are developed or shared;
- analysis of concrete customer reports and fraud investigations;
- continuous improvement and tightening of our security measures.
Our anti-cheat developers are the same specialists who support institutions in fraud investigations. Practical experience from concrete investigations is therefore directly translated into improvements of the platform.
Why we prefer to coordinate security research in advance
Conducting your own pentest or security research can be valuable but also carries risks with anti-cheat software.
Where a regular penetration test usually focuses on improving the security of one organisation, research into anti-cheat mechanisms directly affects the protection of all institutions using the same platform.
During a pentest, insights into the functioning of detection mechanisms and possible bypass routes are inevitably gained. Once such knowledge reaches a wider audience, for example through reports, external suppliers, student assistants, or online communities, it can be used as a basis for new cheats. Commercial providers of fraud and exploit tools also actively follow such information.
Furthermore, it is important for us to be able to fix vulnerabilities in a controlled and careful manner. When multiple parties conduct independent research without coordination, there is a risk that the same information circulates in various places while solutions are not yet available everywhere.
By coordinating research in advance, we can prioritise findings faster, develop solutions in a controlled way, and make them available simultaneously to all customers.
We realise that many institutions, based on their own security policies, are accustomed to conducting penetration tests independently on applications. For traditional software, that is a logical and often desirable approach. However, anti-cheat software is an exception: the goal is not only to secure systems but also to protect knowledge about detection and bypass mechanisms. Therefore, this type of software requires a different form of collaboration, where independent research is most effective when coordinated beforehand.
Schoolyear therefore commissions annual independent penetration tests by specialised external security parties. We are happy to share the results of these investigations with our customers under a suitable non-disclosure agreement (NDA). This way, we provide transparency about the investigations conducted and the improvements made, while operationally sensitive information about detection and bypass mechanisms remains protected.
If additional research from an institution is desired, we are happy to cooperate. By jointly agreeing on the scope, confidentiality, and follow-up in advance, findings can be safely investigated and resolved without unnecessary risks to the exam integrity of other institutions.
Why don’t we inform every customer about every discovered bypass?
When a bypass or circumvention method is confirmed, we always follow the same procedure:
- resolve the bypass as quickly as possible and make it available to all customers;
- inform the reporter about the progress and solution;
- assess whether additional security measures are necessary.
We deliberately do not publish technical details about the bypass nor send a general notification to all customers.
With regular software, disclosure after a patch can help system administrators take additional measures. With anti-cheat software, it is different. Once a solution is available, institutions do not need to take further action; the security has already been updated.
Disclosing the technical workings of a bypass therefore helps future attackers more than current defenders. Even after a specific method is resolved, knowledge about the underlying technique remains useful for future attacks.
We therefore consciously choose not to make this information public. Not because we want to limit transparency, but because we want to protect the exam integrity of all educational institutions relying on our platform.
Support in case of suspected fraud
If an educational institution suspects that a student has circumvented our security, we actively support the investigation.
Our specialists analyse the available event logs, technical debug logs, and the operation of our security mechanisms during the relevant exam session. Where relevant, we also try to reproduce the situation ourselves.
We then share our technical findings in writing, including information that supports the suspicion and information that argues against it.
However, we never conclude whether a student has cheated or not. That assessment always remains the responsibility of the educational institution, which has additional context and information from, for example, the exam platform.
Due to privacy considerations, technical debug logs are automatically deleted after 90 days. Please report suspicions of fraud as soon as possible so that sufficient data is available for a thorough investigation.
How we protect exam integrity together
We see our customers as partners in this ongoing security process.
Therefore, we ask our customers to:
- report discovered bypass methods directly and confidentially to Schoolyear;
- limit the dissemination of information about such methods as much as possible, even after a solution is available;
- coordinate security research and penetration tests with Schoolyear in advance;
- not organise hackathons or similar investigations where students or other unauthorised persons could gain insight into anti-cheat mechanisms;
- share signals or suspicions of possible fraud with us immediately, so we can conduct prompt investigations.
Good anti-cheat does not arise from secrecy alone but from collaboration. Reports from customers, independent research, and our own development continuously reinforce each other. By handling operationally sensitive information carefully, we can implement improvements quickly without creating new risks for other institutions.
This is how we work together towards one goal: reliable and trustworthy digital examinations for all educational institutions.