> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blindsight.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Allow Device Reenrollment

> Clear ONE revoked machine to enrol again, once.

This is what makes refusing safe. Enrolment refuses a revoked hardware_id
outright, which is the only way revocation survives a machine that is still
in someone's hands. Refusing with no way back would make a legitimately
re-imaged laptop permanently unenrollable, and a control that produces
support tickets is a control people stop using: the pressure would be to
revoke less, which is exactly the state this started from.

So the exception is deliberate, attributable and narrow: one device, one
enrolment, expiring on its own within ``_REENROLLMENT_GRACE`` if nobody
uses it, withdrawn by revoking again, and recorded either way.

Gated on ``dlp.manage`` on TOP of the manage grant the rest of these routes
use. Revoking a device and undoing that revocation are not symmetric: the
'developer' role holds ``runtime_security.apps.manage`` and may revoke,
because revoking can only ever take a machine's credential away. Handing it
back is the offboarding control itself.



## OpenAPI

````yaml /api-reference/openapi.json post /api/runtime-security/agent/devices/{device_uuid}/allow-reenrollment
openapi: 3.1.0
info:
  title: Blindsight API
  version: 0.1.0
  description: >-
    The full Blindsight REST surface, generated from the running application.
    Replace the server host with your own deployment.


    For the Runtime Security integration surface (scan, proxy, tool calls) see
    the Runtime Security spec, which is hand written and carries worked
    examples.
servers:
  - url: https://api.your-blindsight.com
    description: Your Blindsight deployment
security: []
paths:
  /api/runtime-security/agent/devices/{device_uuid}/allow-reenrollment:
    post:
      tags:
        - runtime-security-agent
      summary: Allow Device Reenrollment
      description: >-
        Clear ONE revoked machine to enrol again, once.


        This is what makes refusing safe. Enrolment refuses a revoked
        hardware_id

        outright, which is the only way revocation survives a machine that is
        still

        in someone's hands. Refusing with no way back would make a legitimately

        re-imaged laptop permanently unenrollable, and a control that produces

        support tickets is a control people stop using: the pressure would be to

        revoke less, which is exactly the state this started from.


        So the exception is deliberate, attributable and narrow: one device, one

        enrolment, expiring on its own within ``_REENROLLMENT_GRACE`` if nobody

        uses it, withdrawn by revoking again, and recorded either way.


        Gated on ``dlp.manage`` on TOP of the manage grant the rest of these
        routes

        use. Revoking a device and undoing that revocation are not symmetric:
        the

        'developer' role holds ``runtime_security.apps.manage`` and may revoke,

        because revoking can only ever take a machine's credential away. Handing
        it

        back is the offboarding control itself.
      operationId: >-
        allow_device_reenrollment_api_runtime_security_agent_devices__device_uuid__allow_reenrollment_post
      parameters:
        - name: device_uuid
          in: path
          required: true
          schema:
            type: string
            title: Device Uuid
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
components:
  schemas:
    HTTPValidationError:
      properties:
        detail:
          items:
            $ref: '#/components/schemas/ValidationError'
          type: array
          title: Detail
      type: object
      title: HTTPValidationError
    ValidationError:
      properties:
        loc:
          items:
            anyOf:
              - type: string
              - type: integer
          type: array
          title: Location
        msg:
          type: string
          title: Message
        type:
          type: string
          title: Error Type
      type: object
      required:
        - loc
        - msg
        - type
      title: ValidationError

````