Hi,
The possible reason could be :-
The client system's GUID may have changed. As a result, when the client contacts the SEPM after the GUID has been altered, it has the appropriate information to authenticate to the SEPM, but the SEPM does not recognize the client and remediates the client to the Default Group. As a result, any previous policies active on the client are overridden by the policies that are used for the Default Group.
The GUID can be changed due to (but not limited to):
The IP address of the client changing significantly (to a range outside the normal host network that it resides on)
Significant hardware changes to the workstation
A LAN enforcer remediating the client before verifying and authenticating access to the network and its appropriate group
The Default Group is most often used in large deploy situations as a default remediation group with limited rights and policies to handle unrecognized and unknown clients that otherwise have the Symantec Endpoint Protection software installed with a sylink.xml that points back to the SEPM.
When a client appears in the Default Group as a result of the conditions above, move the client back to its appropriate group within the SEPM. For clients that are routinely moving out of the IP range of the network without VPN access, it is best to set a policy to ensure virus definitions are downloaded via LiveUpdate to the mobile client. Do not have the client try to reach back to a SEPM from a foreign IP address as this can trigger the undesired behavior. When setting the client to use LiveUpdate to retrieve definitions while mobile and not attempt to reach back to a SEPM, once the client returns to the home network it should still report back to its appropriate group in the SEPM with an appropriate local IP address.