If you're in a 'transaction' (and assuming you're not using any kind of snapshot isolation or other mechanism that either skips locks or reads previous versions), you could technically update any column to it's current value for the given id (or unique key) - that would prevent you from having to add an additional column for locking purposes.
Example: Table1 (Id int, col2 varchar(10), col3...)
UPDATE Table1 SET col2=col2 WHERE ID = ?
That session would lock that row until a commit or rollback occurs. The locking session is able to freely read the locked row.
You should be able to prototype that by creating a test table, insert a few rows, begin a transaction and update one of the rows without committing and then bring up another SSMS window and try to access that row. The second session should remain blocked until the first session commits or rolls back.
Be aware that any processes (other than the locking process) that require table scans of this table will also be blocked until commit or rollback.