Security Analyzer

The Security Analyzer at https://rotorlab.app/security assesses your aircraft against the UAS Security Verification Standard (UASVS) — an open, vendor-neutral standard published at uasvs.org. Every requirement carries a permanent identifier, an assurance level and a published rule, so any verdict here can be reproduced by anyone holding the same log bytes and the same version of the standard.

Reach for it when a client, an insurer or a procurement officer asks how your aircraft are configured — or before they do.

It reads the same flight logs as the Log Analyzer: ArduPilot dataflash (.bin), MAVLink telemetry (.tlog) and PX4 ULog (.ulg), with the format detected from the file's bytes rather than its name.

What you need#

The Security Analyzer requires an account with the Security Analyzer add-on enabled, or a plan that includes it. Without it, the page shows a Security Analyzer not enabled notice with a link to the Add-ons section of My account.

The Aircraft and Fleet tabs also need Fleet Manager, because they work from registered aircraft. The Assess a log tab works without it — drop in any log and get a result.

The one rule worth knowing first#

A requirement that could not be decided is never reported as a pass.

Some requirements need a person to answer them; some need live state from ground infrastructure that no flight log carries. Those are listed as not assessed, counted separately, and stated in every report and claim. A tool that quietly counted them as passing would produce a much better-looking number and a worthless one.

Every screen therefore shows two figures together: how much was decided, and how much was not.

Assurance levels#

Every assessment runs at one of three levels, which select different sets of requirements:

Level	For
L1	Baseline. Any operator flying on behalf of an organization.
L2	Standard. Public safety, or recurring operations over people or property.
L3	High consequence. DFR, tactical, or contested RF environments.

L2 is the default. Results at one level are never compared against another — they answer different questions.

Assessing a single log#

Open https://rotorlab.app/security.
Choose an assurance level.
Drop a .bin, .tlog or .ulg file onto the upload area, or click to browse.

Nothing is stored. The result appears immediately:

a plain-English verdict — how many red and amber failures are open, and how many requirements could not be decided;
What to fix, worst first, each with the setting to change;
every requirement, grouped by category, filterable and searchable.

Your organization's attested answers and recorded acceptances apply here too, so the same log reads the same way whichever screen you drop it on.

Assessing the logs you already have#

You do not need to upload anything twice. The Fleet tab opens on what is already stored: how many flight logs are held, how many have been assessed, and how many are waiting, per aircraft.

Press Assess stored logs to run them. A log already assessed at that level, against that version of the standard, is skipped — the verdict cannot change, and only the date would move. Tick re-run ones already done to force it.

Assessment is something you run, not something that happens on its own. Nothing is assessed until you ask for it.

One aircraft#

The Aircraft tab covers a single airframe:

Findings — the same results view as a single log, for that aircraft's latest assessment.
Previous runs — the last several runs, oldest first, and what changed between them: which requirement started failing, which was fixed, and which simply stopped being answered. Those are kept apart, because only the first two mean somebody changed the aircraft.
Stored logs — every log held for that airframe, and whether each has been assessed.
Answers — the attested answers that apply to this aircraft only (see below).

The aircraft's own page also carries a Security posture card summarising its latest assessment, with a link straight through.

Across the fleet#

The Fleet tab answers what to do next:

What to fix across the fleet — open failures gathered by requirement, worst first, naming the aircraft each affects. One requirement failing on four airframes is one job, not four findings scattered through a grid.
Configuration drift — requirements your aircraft answer differently. Only requirements decided on every airframe are compared: one that could not be assessed somewhere is a gap in the evidence, not a difference in configuration.
Requirement by aircraft — the full grid, with drift marked.

Questions only a person can answer#

Some requirements only apply under conditions no log can establish — whether a pilot radio is fitted, whether the board carries a hardware safety switch. The standard is explicit that a tool must never infer these from the data it is assessing, so the Operating profile tab asks them in the standard's own words.

Each question shows the requirements your answer decides. Your answer is an attestation: it is recorded against your name and the date, and it travels with your conformance claim.

Answer once for your organization, and override it on the airframes that differ under Aircraft → Answers. An aircraft's answer wins over the organization's, question by question, so recording one exception does not cost you every other answer. Where an aircraft overrides an answer, the organization page says so.

Leave a question unanswered and the requirement is still assessed, with the open question raised alongside the verdict.

What you can do with a failure#

A failing requirement offers up to three actions, and they mean different things:

Accept this risk — the finding is right and you are carrying it anyway. Needs a reason and a name. It moves the requirement from failing to accepted, and accepted is never shown as passed: it stays in the report and in the conformance claim.

Does not apply here — the aircraft genuinely has no such thing. Offered only where the standard gates that requirement on a question a person can answer. This records the attestation, and on the next run the standard itself reports the requirement as not applicable. This is the correct route when, for example, an aircraft is flown with no pilot radio at all.

Flag as incorrect — the finding is wrong; the rule misread this airframe. Needs a reason and a name. It is taken out of the action list and the open counts, and it is still listed — with your reason — in the report and the conformance claim. Flagging changes no verdict: the standard still reports what it found.

Acceptances and flags are scoped to where you made them. One made on the Aircraft tab applies to that aircraft only, so carrying a risk on one airframe does not silently suppress the same finding across the fleet.

Reports#

Two PDFs, both carrying a verification code you can check at rotorlab.app/verify:

Security Assessment — one aircraft or one uploaded log. What was assessed and the log's SHA-256, a severity summary, what to fix with the rationale and the evidence behind each finding, then accepted, flagged, passing, and a full list of everything not assessed.

Fleet Security Posture — what to fix across every aircraft, gathered by requirement, then configuration drift.

The conformance claim#

The Conformance claim tab issues a dated document stating what you attest, backed by machine results anyone can reproduce. It carries every aircraft assessed, the acceptance list, anything flagged as incorrect, and — the part that makes it worth anything — a plain statement of how much of the standard was never assessed.

RotorLab does not certify anybody. Conformance under UASVS is self-attested. The claim reports the evidence behind what you are asserting; it is not a certificate and does not confer one.

Where the results come from#

Each report records the version of the standard it was assessed against, the SHA-256 of the log, and the as-of dates of the advisory and release tables used. A verdict reached against one version of the standard is not a verdict against another, so the Fleet tab counts "assessed at the version in force" separately from "assessed at some point".

Stored assessments are kept per aircraft and per level, with the most recent several retained so each run can report what changed since the last one.