A management agent needs an identity.
Without one, the server would have no trustworthy way to distinguish:
- one endpoint from another
- a known device from an unknown device
- one tenant's endpoint from another tenant's endpoint
remFREE therefore treats initial enrollment and ongoing agent communication as separate phases.
Phase one: enrollment
Enrollment establishes the relationship.
A tenant obtains a temporary enrollment credential through remFREE.
The endpoint uses that credential during its initial enrollment request.
Conceptually:
New endpoint
|
| temporary enrollment credential
v
remFREE enrollment API
|
| validate
| establish tenant relationship
| create device identity
v
Managed endpoint
The enrollment token is not intended to become the permanent identity of the device.
Why temporary enrollment credentials?
An enrollment token answers a narrow question:
May a new endpoint join this organization?
That capability should not need to remain valid forever.
Short-lived credentials reduce the usefulness of old enrollment material if it is exposed later.
Phase two: established device identity
After successful enrollment, the endpoint becomes a known managed device.
Normal operation should rely on the established agent identity rather than repeatedly presenting the initial enrollment token.
Conceptually:
enrollment credential
|
| used once for trust establishment
v
device identity
|
| used for ongoing authenticated operation
v
remFREE
This separates bootstrap trust from normal service operation.
Device identity is not merely hostname
A hostname is descriptive.
It is not sufficient identity.
Hostnames can:
- change
- be duplicated
- be reused after hardware replacement
- be cloned in machine images
remFREE therefore maintains a distinct device identity associated with the managed record.
This allows historical continuity even when display attributes change.
Tenant ownership
A managed device belongs to a tenant.
That relationship must be enforced throughout the management path.
For example, a request targeting a device should not rely solely on a caller supplying a device identifier.
The application must also verify that the caller is authorized for the tenant owning that device.
Conceptually:
User
|
v
authenticated
|
v
tenant membership
|
v
permission
|
v
device belongs to tenant
|
v
operation allowed
Each boundary matters.
Why raw identifiers are not authorization
A device identifier may be difficult to guess, but obscurity is not an authorization model.
Knowing an identifier should never be equivalent to having permission to operate the device.
Authorization must come from authenticated identity and tenant policy.
Re-enrollment
Re-enrollment should represent a meaningful lifecycle event.
Appropriate situations may include:
- operating-system rebuild
- intentional deletion of the previous device identity
- loss of agent identity
- transfer to another tenant
Temporary connectivity problems should normally be fixed without generating a completely new identity.
Clone and image considerations
Machine imaging can create identity problems if a pre-enrolled agent identity is copied into multiple deployed machines.
The correct provisioning model is:
generic image
|
v
unique endpoint
|
v
enroll individually
rather than:
enrolled image
|
+---- clone A
+---- clone B
+---- clone C
|
all claiming one identity
Each managed endpoint should establish its own unique relationship with remFREE.
Identity and audit
Device identity also matters historically.
Jobs, compliance evidence, inventory, and activity should remain attributable to the device that produced them.
If identity is casually replaced, that operational history becomes harder to interpret.
Zero trust in practical terms
The identity model supports a simple principle:
Connection is not enrollment.
Enrollment is not authorization.
An identifier is not permission.
Each layer has its own purpose.
That separation is one of the foundations of trustworthy remote administration.