Alternatively to MBuschi's great idea, you can also look into possibly using an INSTEAD OF INSERT trigger on the DeviceData table. This trigger would first verify the data you need is in the Device table, and then would insert the replicated data into your DeviceData table. (Here's Microsoft's Books Online for Triggers.)
One pro of this solution is it doesn't muck about in your replication setup (should you ever need to script it and redeploy it). While Microsoft offers docs on how to accomplish MBuschi's solution, in general I find the more customizations to a replication topology, the more of a pain it can turn into to manage in the long term.
But an even better pro of using a trigger is that it decouples the data synchronization feature you use from the relational integrity logic you're trying to support. So if one day you decided to switch from replication to another synchronization technology such as SSIS (or even another type of replication), you wouldn't have to re-implement a solution to account for the Device table. Using a trigger ensures that your relational integrity logic is saved at the table level, and is applied no matter where the insert into your DeviceData table comes from.