StudentPrivacy.college
The Privacy Ledger - protect and govern student data

Passwords, Passkeys and Student Accounts

Passwords, Passkeys and Student Accounts: what it means for a student record system, who may use it, and the check to make before it moves.

Privacy check
Record
student record system in security controls for student data
Data
Passwords, Passkeys and Student Accounts
Safeguard
least-privilege access, encryption and access logging
First check
Check that the recipient is bound to use the data only as agreed.

The short answer

For passwords, passkeys and student accounts, think in terms of a chain: a student, a student file system, a purpose, an authorization, a recipient, a safeguard and a retention date. Break any link and the disclosing fails, even if each other link is sound. This guide walks that chain link by link, so the reader may see exactly where a proposed disclosing retains and where it breaks.

Proctoring tools collect some of the most sensitive data on campus, and their adoption needs a higher standard of review than a routine classroom tool.

Governance fails quietly when nobody owns a decision, and the first fix in most institutions is naming an owner, not writing a new policy.

Small releases add up: a series of minor sharings can reveal a picture of a student that no single disclosing intended to produce.

Penetration testing finds technical gaps, but it does not test whether a sharing decision was lawful, and both tests are required.

What this covers

Disclosures to other schools where a student seeks to enrol are permitted, but the student ought to be told that such disclosures occur, via the yearly notification.

Directory information is a defined subset that an university might designate and publish, and the designation must be published before it is relied on.

Health and counselling platforms should be segregated from broad student platforms, with access limited to the staff who provide the care.

Undocumented students face grave consequences from record disclosure, and staff should be especially careful about disclosing that could reveal status.

Disciplinary releases to victims and others have particular limits, and the outcome that may be shared depends on the offence and the recipient.

Applicants who never enroll still have records that were created regarding them, and those records should be retained and safeguarded on a specified schedule.

How to work through it

Set security baselines before a new platform launches, because retrofitting safeguards following adoption rarely restores information previously shared.

Retain audit evidence on a specified schedule, since evidence deleted too early cannot support a later defence, and evidence kept too long becomes a record of its own.

Read exemptions narrowly and on their own terms, and do not stretch an exception to cover a purpose that merely resembles the named one.

Put vendor terms in the contract, not in a sales deck, and check that the contract names the data, limits its use and needs removal on exit.

Include students in governance, because students notification confidentiality problems that staff have normalised.

Design age screening to collect as little as possible, because screening that collects more than it needs becomes the problem it was meant to solve.

Protect alumni records with the same care as current records, because graduation does not end the university's duty.

Tell students through the annual notice that releases to schools where they seek to enroll occur, because surprise releases damage trust even when lawful.

A worked illustration

In that illustration the sharing is limited to the disciplinary purpose, and the record is not treated as an ordinary student file afterwards.

In that illustration the officer verifies the disciplinary sharing limits, confirms what may be shared, and gives the media a written, limited answer.

Consider a health centre that discloses treatment files with a broad student system by accident, and that treats the accident as an event, not as a clerical slip.

Consider an education analytics project that begins with a question about storage and ends with a dashboard that nobody may explain to a student.

In that illustration the faculty member pauses, the confidentiality officer reviews the tool, and the course adopts a tool whose contract excludes training use.

Where guides go wrong

Mixing health or counseling records into broad student systems is a mistake that is hard to undo once the information has spread.

Responding to a media request from the first office that answers is a mistake, because the first office is rarely the office that knows the disclosure limits.

Accepting a vendor's self-assessment as evidence, where the data is sensitive, is a mistake, since self-assessment answers the questions the vendor chose to request.

Letting group mailboxes and shared drives accumulate members without an owner is an error that turns access control into archaeology.

Retaining audit evidence too long is an error of its own, because evidence kept beyond its schedule becomes a record that itself needs safeguarding.

Sources and evidence on the record

  • Family Educational Rights and Privacy Act regulations, 34 CFR Part 99, text on eCFR.
  • National Institute of Standards and Technology, Computer Security Resource Center - control guidance used here as method, not as law.
  • US Department of Education, Student Privacy Policy Office, studentprivacy.ed.gov - FERPA guidance, FAQs and model notices.

Evidence basis: 34 CFR Part 99 and NIST control guidance used as method Applies when: When a college holds, uses or discloses a student record system in the context of security controls for student data

Next on the ledger