Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Run device attestation after enrollment and periodically (Desktop)

Open
  • Is something wrong?
#3,735 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
desktop, security

Research direction

Start by tracing the desktop enrollment flow and the existing periodic posture-data checks, including disk-encryption checks. Then follow the core's EK certificate validation and device-status updates; done means all listed enrollment, periodic, failure, fingerprint, CA, and unsupported-client scenarios produce the specified statuses and metadata.

Written by the indexing model from the issue text.

Description

User story

As an admin, I want each device to be attested when it's enrolled and periodically afterwards, so that its attestation status is always current.

Acceptance criteria
  • The desktop client runs attestation automatically after the device is enrolled, with no user action.
  • The client re-runs attestation periodically, using the same interval and mechanism as the existing posture data checks (e.g. disk encryption).
  • The core validates the device's EK certificate against the EK CA database, including manually added CAs:
    • The certificate chains to a known CA → Attested.
    • The attestation is valid but the CA is unknown → Unrecognized (#3734 ).
    • There's no TPM, the attestation is invalid, or the client doesn't support attestation → Not attested.
  • Each successful attestation stores or updates the attestation date, certificate owner and fingerprint.
  • If a previously attested device fails a later attestation, its status changes to Not attested.
  • If the device's fingerprint changes, its verification status is reset to Not verified.
Test scenarios
  1. Enroll a device with a supported TPM → it becomes Attested, with a date and fingerprint, without any user action.
  2. Enroll a device with no TPM → it becomes Not attested.
  3. Enroll a device with a TPM from an unknown CA → it becomes Unrecognized.
  4. Wait for the next periodic check → the attestation date updates.
  5. Make attestation fail on an attested device (e.g. disable the TPM) → at the next periodic check it becomes Not attested.
  6. A verified device reports a different fingerprint → it becomes Not verified.
  7. An older client without attestation support → the device is Not attested.
Notes
  • Use the device's WireGuard public key as the attestation nonce. This binds the attestation to the client configuration.
  • Attestation results will be part of every config polling request and stored in Core. Separate #3782
Dominant language
Rust
Stars
2.9k
Forks
119
Avg merge
1d 2h
Merged PRs (30d)
61

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DefGuard/defguard

All issues in DefGuard/defguard

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.