Cybersecurity thesis drafts are frequently sent back for six recurring reasons: an undefined or shifting threat model, a claimed attack or defence that is not reproducible from the write-up alone, no named framework behind a risk or severity score, an evaluation that changes more than one variable between test conditions, a legal or ethical gap around active testing on systems the student does not own, and a literature review that cites vendor blog posts as if they were peer-reviewed findings. A faculty checklist built around these six, applied before a draft leaves the supervisor’s desk, catches much of what an external examiner would otherwise flag.
Why does an undefined threat model send a draft back?
A methodology or design chapter that describes a defence, detection method or vulnerability assessment without first stating who the adversary is assumed to be — their capability, access level and motivation — cannot be properly evaluated, because “does this defence work” only has an answer relative to a specific threat model. A draft that shifts its implicit adversary between chapters (a low-skill opportunistic attacker in the introduction, a sophisticated nation-state actor by the evaluation chapter) reads as internally inconsistent even when each individual claim is defensible. A supervisor checking for this before submission should be able to point to one paragraph that states the threat model explicitly and confirm every later chapter is consistent with it.
Why does an examiner ask for reproducibility on a claimed attack or defence?
A cybersecurity thesis making a technical claim — a vulnerability exists, a detection method achieves a given result, an attack succeeds under stated conditions — needs enough detail in the write-up (tool versions, configuration, dataset or environment specifics, exact steps) that another researcher could attempt to reproduce the result without contacting the author. A results chapter that reports an outcome without this detail, often because the student is treating the specifics as obvious or as a security-through-obscurity concern, reads as unverifiable rather than confidential, and an examiner who cannot check the claim will ask for the missing detail before accepting it.
Why does a missing named framework behind a severity score get flagged?
A thesis that assigns a risk rating, severity score or maturity level to a vulnerability, system or process needs to name the framework behind that score — CVSS for vulnerability severity, a named risk matrix, or a named framework such as the NIST Cybersecurity Framework or a published maturity model — rather than presenting a number as if it were self-evidently objective. A student who invents an ad hoc scoring scale without grounding it in a named, citable framework, or who applies CVSS incorrectly (scoring exploitability and impact inconsistently with the standard’s own metric definitions), gives an examiner an easy, specific objection to raise, and it is a common way a technically sound piece of work loses marks on presentation of results.
Why does changing more than one variable between test conditions matter so much here?
A comparative evaluation — this intrusion-detection configuration versus that one, this hardening approach versus the baseline — needs to hold every variable constant except the one being tested, the same controlled-comparison discipline any experimental field requires, but it is a particularly common failure in cybersecurity theses because the test environment itself (hardware, network conditions, traffic generation, dataset freshness) has many moving parts that are easy to let drift between runs without noticing. An examiner who spots that the “improved” configuration was also tested on a different dataset, a different day, or under different load than the baseline will treat the comparison as uncontrolled, regardless of how favourable the headline result looks.
What legal and ethical gap around active testing gets caught most often?
A thesis that involves scanning, probing or attempting to exploit a system needs explicit authorisation on record for every system tested — a signed agreement or a documented safe-harbor scope, not a verbal understanding — and needs to state that authorisation in the methods chapter, not just hold it in a filing cabinet. Testing against a live system without documented authorisation, even a system the student believes they have informal permission to test, is a quick way for a cybersecurity thesis proposal to be escalated to a full ethics and legal review rather than a standard methodological one, and a draft that omits the authorisation statement entirely reads to an examiner as though the question was never considered.
Why do vendor blog posts and marketing pages get rejected as literature-review sources?
Cybersecurity moves fast enough that some genuinely useful technical detail appears first in a vendor security-research blog or a conference talk rather than a peer-reviewed journal, and a thesis is not wrong to draw on those sources for current, specific technical detail. The failure is citing a vendor blog post as though it carries the same evidentiary weight as a peer-reviewed study when making a comparative or causal claim — “Vendor X’s research shows this approach reduces false positives by half” treated as an established finding rather than as an industry claim worth noting and then testing independently. A literature review should distinguish explicitly between peer-reviewed evidence and industry-reported claims, and treat the second category as a hypothesis to test, not a result to cite.
How should a supervisor use this as a pre-submission checklist?
Six questions, checked against the draft before it goes to the committee: is the threat model stated explicitly and held constant across chapters; is every technical claim reproducible from the detail given in the write-up; is every risk or severity score grounded in a named framework; does every comparative evaluation change only the one variable under test; is testing authorisation documented and stated in the methods chapter for every system involved; and does the literature review distinguish peer-reviewed evidence from industry-reported claims. A draft that clears all six is not guaranteed to pass examination on every other ground, but it will not be sent back for any of these six cybersecurity-specific reasons.
How does this differ from generic thesis-writing feedback?
Generic feedback on clarity, structure and argumentation applies to a cybersecurity thesis the same way it applies to any field, and this site’s look at consistent marking of extended written work covers that calibration question at the examiner level. The six objections above are different: they are failure modes specific to what a cybersecurity thesis is actually claiming — a technical result, a comparative evaluation, an authorised test — and a generic writing-quality checklist will not catch a threat model that shifts between chapters or a severity score with no named framework behind it, because those are field-specific substance problems, not writing-quality problems.
Does the code-similarity question overlap with any of this?
Where a cybersecurity thesis includes a substantial code component — a tool, a proof-of-concept exploit, a detection script — the discipline covered in this site’s piece on code-similarity tools for computer science departments applies to that component specifically, as a separate integrity question from the six technical-substance objections above. A thesis can pass every one of the six checks here while still needing a code-originality review if it includes a significant codebase, and the two checks should run in parallel rather than being treated as one combined review.
Where does an AI-assisted proof-of-concept or exploit script fit in a supervisor’s review?
A cybersecurity thesis that used an AI coding assistant to help write a proof-of-concept script or a detection tool raises the same disclosure question covered in this site’s piece on what a computer science faculty’s AI-use policy should say about code, applied here to security tooling specifically: the policy question of what must be disclosed and how is a department-wide computer science and cybersecurity question, not something the six technical-substance checks above address on their own. A supervisor reviewing a cybersecurity draft should confirm the department’s AI-use disclosure requirement has been followed for any code in the thesis, as a seventh, policy-level check that sits alongside the six field-specific ones rather than replacing any of them.
What happens when a threat model is technically correct but never stated?
A surprisingly common variant of the threat-model objection is a draft where the student clearly had a specific, coherent adversary in mind throughout — the design choices are consistent with it — but never wrote that adversary down as an explicit statement anywhere in the thesis. An examiner cannot credit reasoning the text does not contain, and a technically sound design built around an unstated threat model reads, on the page, exactly like a design built around no threat model at all. The fix costs a student one paragraph and an afternoon; catching the gap before submission, rather than at the viva, is what a supervisor checklist is for.
Where Tesify fits
The technical-substance judgment — whether a threat model is coherent, a result reproducible, a severity score correctly grounded — stays with the supervisor and the examining committee; none of it is a writing-platform decision. Once a draft has cleared these checks and a student is writing up the final text, Tesify is the platform candidates use to write their own thesis chapter by chapter: more than 9,000 students have written over 15,000 chapters with it, and the thesis stays 100% written by the candidate. See how Tesify supports a cybersecurity thesis cohort.
Frequently asked questions
What is a frequent reason a cybersecurity thesis draft gets sent back?
An undefined or inconsistent threat model — the assumed adversary’s capability and access level shifting between chapters without being stated explicitly anywhere in the draft — is among the recurring objections, alongside non-reproducible claims and ungrounded severity scores.
Why does an examiner care about reproducibility if the vulnerability is sensitive?
Confidentiality and reproducibility are separate concerns. A thesis can redact identifying details of a real system while still providing enough configuration and methodology detail for another researcher to understand and, in principle, reproduce the finding.
What framework should back a vulnerability severity score?
CVSS is a widely used named framework for vulnerability severity; a named risk matrix, the NIST Cybersecurity Framework or a published maturity model are alternatives depending on what is being assessed. The requirement is that some named, citable framework backs the number, not that CVSS specifically is mandatory.
Does informal permission count as authorisation for active testing?
No. A thesis involving scanning, probing or exploitation needs documented authorisation — a signed agreement or a recorded safe-harbor scope — stated explicitly in the methods chapter, not a verbal or informal understanding.
Can a thesis cite a vendor security blog at all?
Yes, for current technical detail, but a comparative or causal claim sourced from a vendor blog should be treated as an industry-reported claim to test independently, not cited with the same evidentiary weight as a peer-reviewed finding.
Is a code-originality review the same as this checklist?
No. This checklist covers technical-substance objections to the thesis’s claims and evaluation; a code-originality review is a separate integrity check for any substantial codebase the thesis includes, and the two run in parallel.
Does using an AI coding assistant need separate disclosure from this checklist?
Yes. AI-assisted code in a thesis is governed by the department’s own AI-use policy, a distinct disclosure question that sits alongside, not inside, the six technical-substance checks a supervisor runs against the thesis’s claims and evaluation.
Can a technically correct design still fail on the threat-model check?
Yes, if the adversary the design is built around is never stated explicitly in the text. An examiner evaluates what the thesis actually says, not what the student privately had in mind while designing the work.